Software Architecture Guide - <AUTHOR> https://martinfowler.com/architecture/ <comment><USER2> I gotta say I am surprised and a little disheartened by all the negativity around this post and Fowler in general. Fowler's writing has been a huge inspiration to me in my career. I'm about to gift a copy of his book "Refactoring" to one of the junior engineers I work with for instance.

I think the idea of an architecture as a social construct is very fitting. Software is hard when multiple people are working on it with differing backgrounds and experience. Having a rough outline (emphasis on rough here) of "what lives where" and "what is allowed to talk to what" is absolutely critical IMO. It's how your team can effectively reason about a system and add new features to it. It should also be a living thing in that it's something that is continually refined, discussed, and changed as the needs of the business change. Done right, its an organic process that really helps deliver more robust software that everyone involved has a high level understanding of.

Contrast that with an Architecture (capital A) done in Enterprise which delivers a static artifact that does not allow for any creativity and micromanages every aspect of it. It's split off into chunks and no one without an expert level of knowledge can easily understand it. That kind of design will almost certainly fall over the first time there needs to be a change to it. It's important to point out the difference because that is NOT what Fowler is recommending in his writings.

<comment><USER3> Totally. In a side room at Java One in 1999 or 2000 I saw Fowler talking about Refactoring, and he happened to bring Kent Beck up on stage to talk a bit. If I hadn't been exposed to their ideas, I surely would have left software by now.

Over and over, my experience was building something that slowly got less tractable over time, where eventually we'd just want to do a big rewrite. It sucked! I had tried the big-design-up-front approach, where I thought real hard for a long time before building. That might push out the rewrite date some, but definitely not forever. It was dispiriting, a slow, sticky death. That combined with crunches and burnout was slowly making me hate something I had loved doing.

But their main point was that code bases didn't have to end in an entropic snarl. That with decent tests and a little elbow grease, code could get better organized every time we touched it. That instead of death by papercut, we could make things a little better every day. Better for the users, better for the business, better for the developers. They weren't promoting silver architecture bullets. They were saying that we should trust and empower teams to figure it out. That if we gave them room and tools to figure it out, everybody would end up happier.

It made a huge difference in my life, so it's weird to see people here aggressively putting words in Fowler's mouth, words that seem entirely at odds with my experience of him and his work.

<comment><USER2> Thanks for taking the time to write this. I really hope that the latest generation of developers don't see all the negative HN hive mind comments and discount writings like this.

</comment></comment></comment><comment><USER4> Lots of hate in this thread.. People asking for proof: what sort of evidence would convince you? I take these blog posts, apply it to my experience, and take what I think makes sense. Sometimes, an idea will solve an obvious pain I've had. Sometimes, an idea will show me a pain I didn't know I have. Sometimes I disagree with the idea because it won't work for me. That's fine. I'm still much better off thanks to this literature, and I would be worse off if it all had to be evidence-based.

If you think you can write better based on your experience, please go for it. I'd love to have more literature to read, analyze, and learn from. If you can't (pressed for time, etc), and only have time to post in HN comment threads, then at least discuss concretely which parts you disagree with so we can learn from that too (I'm serious, not being facetious). If you can't even do THAT, then sorry, all your valuable experience is way less useful than someone like Martin Fowler, because I'm not learning anything from you.

Having a good understanding of how to architect code is hard. Being able to write about that in a way that's useful for others is even harder, and is a skill of its own.

So personally, I thank Martin & Co for all their writing.

<comment><USER5> Yes. And Computer Science is not a science, and Software Engineering is not an engineering.

Guides to it are more like guides to writing. _Strunk and White_ , where is your empirical data? What's your control? Where are your PDE's?

Some also have aspects of business productivity books, with well-known common- sense ideas, like _In Search of Excellence_ (which made up case studies, and a co-author said what's the problem?)

Even Fred Brooks' _Mythical Man-Month_ \- informed by his leadership of the massive bet-the-company "360" project at IBM - lacks data. It's still great though (in, uh... my subjective opinion, I guess).

<comment><USER6> Software engineering is engineering in the same sense the mechanical engineering is engineering.

The only difference is that with software your materials are descriptions. I.e. you describe something, give to the computer and the computer turn itself into this something .

In the end, there is a physical entity in the world (the hardware), which turned itself into a unique machine based on your description (for example an ATM).

While in mechanical engineering, you materials are physical, which might make it easier to explain.

<comment><USER4> I disagree. Engineering disciplines vary in how far removed they are from the underlying physics and how malleable they are. Building a bridge (or civil engineering) is very connected to the underlying physics. A set of equations give you the answers. It's also not malleable. You design it once, then build it, putting in some margins of safety to account for any variances in underlying material or potential usage, then it's pretty much not malleable.

Mechanical engineering is a little more removed. You have moving parts, interconnected pieces, wear and tear, etc. Now you have to lean heavily on preventative maintenance, ability to replace worn parts, etc.

Hardware is more removed. Software is even more removed. The laws of physics are there, but there are so many man-made layers of abstractions on top of it that "good architecture" is a lot less like what you'd expect in a typical engineering discipline.

Not saying any is easier than the other, just that they are very different disciplines.

<comment><USER6> There is not such thing is "partial" engineering.

Engineering is the creation and ongoing management of any real world object (building, cars, bridge, computer) which has affect on its environment. I.e. they are placed in the real world to achieve some sort of a function.

The role of the engineer is:

1) Find out what function a machine should provide

2) Create this function by building the artifact on time, and in cost effective manner.

An artist on the other hand:

1) Does not care about the function. I.e. if the thing is useful or not.

2) Does not care about the time/cost etc.

The fact that software is just a description (bunch of text files), does not mean that it does not affect the real world.

As I said, the machine in the real world is the general propose computer. The computer understand this text files, and turn itself into the machine.

<comment><USER4> I didn't say anything about partial engineering. Just that engineering disciplines are different. If you need to design a column to hold up some load, a set of equations will tell you the dimensions of that column, how much cement, sand, etc to put in the concrete mix, how many steel rebars of what diameter and specification. Designing that column is _very_ different than anything I do as a software engineer.

<comment><USER7> But, if you need to design a data processing system with a certain throughput, a set of equations can tell you how many servers you will need, how much storage, constraints on latency or network bandwidth, etc. So it's not so different after all.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Reading an enumeration of architecture options can be helpful, but I've probably found more value in works like Ousterhout's "A Philosophy of Software Design" that cover fundamental design principles. Such principles seem to be applicable no matter the project.

I appreciate that Ousterhout tries to support these principles with some data from his own experience (building Tcl, RamCloud where Raft consensus was discovered, etc) and from code reviews of student projects in his design course, but he admits that there is a lack of data about things like design.

Sample principles from Ousterhout:

* When developing an interface, favor exposing a small number of functions each with deep functionality over exposing a large number of functions each with shallow functionality. For example, favor Unix file I/O interface (open, close, read, write, unlink) over Java file I/O interface (File, FileReader, BufferedReader, FileWriter, BufferedWriter, FileNotFoundException, ... etc.)

* When choosing between keeping your code specific and keeping your code general, favor "somewhat" general. For example, instead of exposing "deleteNextCharacter(text, pos), deleteNextWord(text, pos), deleteNextSentence(text, pos)", just expose "delete(text, pos, length)" and let the caller use it how they will.

<comment><USER9> Yes, "A Philosophy of Software Design" is brilliant, precisely because the author supports their statements through the many experiments they performed with students and

The fact that they're the author of a well-known piece of software helps, although we should not use this as the main criteria to evaluate a text.

Offering at least evidence based on experimentation is essential if we want to move past personality cults and having entire teams work based on what someone wrote on a blog somewhere.

<comment><USER10> I'm wondering whether another factor that might be at play is that as consultants they may not be at liberty to discuss that kind of detail. Barring that, it would be interesting to have Fowler sit in Ousterhout's class, take on an advanced problem and see what they come up with.

</comment></comment></comment><comment><USER11> > All I see is yet another reasonably sounding yet unsupported piece of > folklore.

Another artefact of the fact that software developers are still craftspeople - as in "someone skilled at making things by hand".

Software development output is something that no-one has yet successfully quantified. There's no easy metric to assess a non-productive software developer from a productive one. We can all tell the difference, but good luck measuring it. In my country, which (thankfully) lacks America's "at-will" employment contracts, it does mean that it's quite hard to fire an underperforming dev, because how the hell do you prove they're underperforming? What metric do you use?

Bug rate is a bad one, because very smart people working in a new problem domain may register an significant uptick in bugs - doesn't mean that they're incompetent, it's just the result of doing new stuff in an unfamiliar domain in a highly complex environment.

Lines of code? The less said about that metric and how gameable it is, the better.

Us still being craftspeople is also why we can command such high wages relative to the rest of the economy - what we do is not yet automated, so we can still draw a premium.

<comment><USER12> > it does mean that it's quite hard to fire an underperforming dev, because > how the hell do you prove they're underperforming? What metric do you use?

I think your criticism of 'at-will' employment is unfounded in this scenario. Having lower guardrails on employment means it's not as pressing to figure out performance metrics. If the company narrative is that an employee is helpful to the mission, then there isn't much cause to fret for a more perfect metric. And at-will means you can test more employees before committing to a few for longer than a couple years.

<comment><USER11> I didn't express any direct or detailed criticism of at-will in my comment, just my gladness that we don't have it.

Why, despite the difficulties it causes me when dealing with poor performing devs, am I happy we don't have at-will?

Because at-will dramatically distorts the employer - employee social contract in favour of the employer. And employers already have a disparately large amount of power over their employees as it is. So there you go, that's my criticism of at-will employment. It puts the well being of the employer ahead of the well being of the employee.

You can have a trial period without "at-will".

<comment><USER12> Gladness you don't have it _is_ criticism you're trying to hide behind semantics.

You and I seem to have different ideas of an employment social contract (or non-existence of one). Unless you're interested to dig into that difference, I don't think we have anywhere else to go with this thread.

<comment><USER13> Gladness: "I'm glad i don't have a million dollars to manage in my bank account, just getting the best from my small savings is stressing me out!"

Thankfully: "My bank account (thankfully) lacks a Bill Gates' sized stash of greenbacks, it does mean that it's impossible to buy a mansion though"

I'm not criticising the concept of a million dollars in either of these statements. Thankfully, as used in the original context means something quite different to the meaning you've derived.

I might still actually have a bone fide criticism of a million dollars, but that's neither here nor there in the context of either statement.

I think wrapping it up's a fair shout though so no hard feelings and all the best.

</comment></comment></comment></comment></comment><comment><USER14> I looked at this thread a while back and closed the window, hoping that those early comments don't influence the younger practitioners who are on HN.

As someone nearing 40 (mainly doing consulting work around boring business apps for a long time), my view is that Martin Folwer's biggest contribution is indeed the documentation, and defining the vocabulary to enable discussion around frequently encountered (but perhaps mundane) problems in Enterprise Application development. He isn't trying to break new ground, but I'm glad his writings exist. To pick a very random example, here's CQRS defined in an approachable manner[1]. It's a great link to send to a team of 50, out of which quite a few will be fresh out of college. And I am pretty sure Martin Folwer has seen plenty of real world code while he was working at Thoughtworks. The ideas in his writings aren't conceived in some vaccuum.

Some of his early writing isn't perhaps as relevant today. For instance, he talks about the flaws of Anemic Domain Model here [2]. Back in the day, many of us tried to enrich the domain model with particular emphasis on reusability. But those things are less relevant in today's heterogeous environments where logic lives across in multiple services (many outside your team's control). So just reading through his site will surface a lot of outdated ideas; but that's helped a lot of companies along the way when we didn't have to aim for web-scale tps. Actually, it might still work for 99% of apps even today.

HN tilts towards the experiences of Startups and young founders, but one good lesson to learn early is that we should be more open minded.

1: [https://martinfowler.com/bliki/CQRS.html](https://martinfowler.com/bliki/CQRS.html) 2: [https://martinfowler.com/bliki/AnemicDomainModel.html](https://martinfowler.com/bliki/AnemicDomainModel.html)

<comment><USER15> I don't understand how anemic domain models are irrelevant now especially in a time where a lot of software practitioners seem to observe domain driven design. In the age of microservices, it is very important to determine clear context boundaries. "Logic lives across multiple services" sounds more like a design smell to me. In this case, changing even very simple business requirements could mean changes in multiple parts of the system, which could mean multiple redeployments of many different services. Also implies more complex integration (even e2e) testing.

<comment><USER16> I'm definitely guilty of using and promoting anemic models. I find that teams have a hard time deciding whether logic is service or domain or whatever and gravitate towards putting everything in one place _if_ domain objects are allowed to be at all smart. On the other hand, people do well with the rule that logic belongs in procedural layers with clear names and some sort of maximum size/complexity.

I also find that these discussions matter less in microservices because the size of each service is so small that you usually don't need more than two layers: one for business logic and one for persistence.

I very much agree that microservices create their own challenges at service interfaces, but since these boundaries are usually expressed as http operations instead of object oriented function calls, I look for different solutions, especially various forms of system-wide introspection and testing.

<comment><USER17> First, anemic models work well in service contexts. You can't send a business rule from a web page to a web service as part of a data entity. And so such models have a valid place in the world.

Micro services are still services. As such we always validate data crossing a trust boundary - whether monolith or micro service. The rules to do that validation cannot travel with the data.

So guilt because anemic strikes me as... odd. Modern connected apps aren't written as single-tier Smalltalk apps.

<comment><USER18> You wouldn't send a business rule from a web page, you'd put it in the domain model on the server.

The web page has a UI model, not a domain model.

<comment><USER17> That's the point. And yet Fowler objects because it violates encapsulation and information hiding, because it requires a service layer and makes a model less expressive.

<comment><USER15> You can easily serialise a well fleshed out (i.e. non-anemic) object. Does the view layer in this particular example need to know the encapsulated business rule? In my experience, not usually. Otherwise, there's most likely a problem with responsibilities. And when that data comes back from the UI, it's also relatively easy to reconstitute it back to well fleshed out objects.

<comment><USER17> This I know. The point isn't how one might do it, or whether it can be done¹. The point is that Fowler has issues with anemic objects, even though there are patterns in distrubuted computing best solved by anemic objects.

¹ Note that reconstitution does not do away with anemic objects - reconstitution does not implement logic in a purely object-oriented way, i.e. the logic does not travel, but the data does.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> The Enterprise Architect's job is rather more like that of an Urban Renewal Planner than an architect. There are many pre-existing structures, many interested parties with varying degrees of control, and many economic and technical constraints to be satisfied within a larger political system.

</comment><comment><USER20> People have asked for evidence on this thread, so let me share my experience. A couple of years ago, I was developing an E-Commerce platformm internally for my company. I follow Martin Fowlers' articles on using DDD (Domain Driven Design) and Microservices to architect applications. What should have been a month long project took us 8 months! I'm not including the time I took to read about, understand and practice DDD and the surrounding concepts. Every DDD book is atleast 500 pages or more. And none of them are clear on the concepts, and are mostly full of fluff.

To give you more details, our stack was based on Phoenix, but it used a concept called Umbrella applications (basically Micro services pattern). Along the way, I hit so many snags and I thought I must be doing it wrong. Because, that's what these authors kept saying all the time to people who had failed to implement their preachings. So, I met a couple of people who had actually done this DDD on a much larger scale than I had and even they shared the same experience and stories of failure and struggling. Still, I shrugged them off thinking it must be something we were doing wrong instead of DDD/Fowler's teachings itself. In the meantime, we were struggling to launch features for our E-Commerce software because our microservices architecture based on DDD was just a house of cards at this point. And then, I finally called up someone I knew who had done DDD successfully and asked him how he did it. He said one of the authors of a popular DDD related website, had offered to consult for his company. And they had no choice but to employ him because they were pretty invested at this point. After a while, I started meeting a bunch of such companies who got their DDD setup done by either authors or by some vendor these authors had a stake in.

And then BINGO, it all made sense - most of these patterns/shortcuts/discoveries/secret sauces by these authors are hardly tested by them. It's just a way to sell you more consulting and training.

A couple of weeks later, we hosted a casual meetup for tech talks in our area and we got to meet more folks who had followed the same path and failed. We finally decided to do a small hackathon over a weekend and get our projects done. In the end, in about 3 days from Fri-Sun, we had got done so much more with a monolithic architecture than we had ever gotten done with DDD and microservices. Today, my platform is in production and is a proud monolithic app and still going strong.

It was perhaps the most expensive lesson I've ever learnt, but one that I will remember for a long time.

<comment><USER21> 2015: [https://www.martinfowler.com/bliki/MonolithFirst.html](https://www.martinfowler.com/bliki/MonolithFirst.html)

<comment><USER20> I remember this article very well. When it was published, it was too late as we were already following his articles on DDD before that. This is what I meant when I said the authors said we were doing it wrong. This was published after realizing a lot of people who took these authors' advice and went down the DDD path weren't happy and shot themselves in the foot.

<comment><USER22> There is some ongoing confusion here. Using domain-driven design has no bearing on microservices vs. monolithic architecture.

</comment></comment></comment></comment><comment><USER23> I have been building large scale/distributed systems myself and reviewing designs of systems like these being built around me, for years now. I have never come across any of the type of ivory tower architecture that this post and other sofware architects write about. We're talking about real-world systems that are high-load and somewhat novel, with battle-scarred engineers building them.

I find it ironic that that many of the people who write about architecture are consultants or writers. Consultants usually come into a project, make some decisions and write some code in a few months. Then they leave, without having to maintain the application. Of course they bring in fancy-named architecture patterns as one-size-fits-all solutions, leaving before the cracks on the approach show. Ever notice how little writing there is about iterative software design?

For writers, it seems they build a simple proof-of-concept solution, that is never deployed in production, documenting this process and showing it off as an example.

Yet, when it comes to writing about software architecture, this is 90% of the materials. Engineers who build this day in, day out, design systems from inception, iterate on them, code and deploy, then maintain and operate them for years - they barely share what approach they took. And it's none of this fancy-talk in articles like this one. It's not UML or other formal methods. It's simple documents, simple diagrams, lots of discussion about tradeoffs and tons of back-and-forth comments over Google Docs/O365 and in real life.

I'm at the point where I'm serioulsly debating writing something more substantial on how _actual_ software design works at tech companies, when you're not a consultant or a writer, but an engineer who does this full-time, end-to-end, living with all the consequences of decisions and fixing mistakes after.

On the importance of prototyping, extensible MVPs, whiteboarding, documenting an initial design and getting feedback, iterating on it, architecture jams, design war rooms - and when starting again when the world/business changes substantially, keeping things running and migrating things over to the new system.

<comment><USER24> I've worked in both a big IT orgs and consulting and the Ivory Tower Architecture people are 10X more prevalent in IT orgs. They're the ones who establish architecture review boards and request extensive documentation and rounds of approval before allowing a project to proceed. On the consulting side, we typically define an approach which might as simple as saying "We're going to write microservices, mostly in Python and our main data store will be Redis until we pick something better" and then start iterating.

<comment><USER25> When consulting I love those guys. So many billable hours and project delays with pay.

</comment></comment></comment><comment><USER26> Martin always has good points. What I miss from him is proofs. The weeks vs months part crossover for internal quality... How is it measured? Is it just a thought, or a wish?

<comment><USER27> In the public sector of Denmark we've been on a decade long journey toward better Enterprise Architecture. We have national guidelines for how we want public system/services to be build and how they should be able to transfer data through APIs. We don't get completely technical, telling you what tools you need to use to build your software, only how your software needs to fit into the environment that is public sector digitalisation.

The reason we do this is because we've seen what happens when we don't.

The municipality where I work operate a pretty common amount of IT systems. We don't know exactly how many because there isn't a centralised unit to handle them all, but our guess is 300 different IT systems. There is a lot of common things these systems need, like authentication. That used to be terrible. Before web-services and federated IDPs it was quite literally maintaining our organisational hierarchy in 300 different IT systems manually. And that's just our place, in Denmark we have 98 municipalities that all have 300 IT systems run by different suppliers. With a common architecture we defined how organisational data needs to be interpreted by these systems, we also build a single co-owner database where each municipality could make these data available in the same defined format, through the same APIs.

It's already saving us millions, just from this tiny piece of the much bigger picture. It's not been without backlash either, because as it turns out, private tech companies don't actually want to build the smartest systems. They want to sell us silo systems, because then they can sell us access to our data 300 x, where 1x could be organisation data and another x could be statistics.

Anyway, I think we have evidence that architectural choices matter a great deal. At least when you look at it from an enterprise sized point of view.

With that said, I'm not sure I buy detailed application architecture, where you design everything in your favourite markup-language, either. We certainly have no evidence to support that this sort of architecture isn't just a waste of time. But for the big picture, in enterprise sized organisations, you can't live without IT-architecture if you want to be efficient.

If you want to read more about it, you can at: [http://info.rammearkitektur.dk/index.php/Forside](http://info.rammearkitektur.dk/index.php/Forside) but it's in Danish.

<comment><USER28> It sounds more like someone actually sat down and thought about what to do before doing it.

I read danish. I have experience with it. I did not understand what the page was trying to say.

Providing your data through APIs are often a better way than rolling your own manual delta sync through reports every Sunday uploaded to your company FTP server with 5% downtime.

Not duplicating your data throughout various systems is not architecture it's just common sense.

<comment><USER27> > Not duplicating your data throughout various systems is not architecture > it's just common sense.

I wish you were right about that, I really do. Unfortunately only 7 of our 300 IT systems do this today. As rammearkitektur compliance is now a required part of public procurements that number is going to go up, but only because we're forcing this architecture upon the private tech houses.

If we didn't we would never see 95% the APIs we so desperately need, and the last 5% would cost us half a million each. That's how it's been for 30 years, and it's only changing because of enterprise architecture.

</comment></comment></comment></comment><comment><USER17> Oh man. Another diatribe from Martin Fowler™.

Takes me back to the 90's when I was in awe of teh architectures and architects, understanding of which was always just beyond my grasp.

99% of software I've encountered has some kind of interface, a domain it operates in, and data it operates on. Call these three things layers. It also has some cross-cutting things that are universally available in the software - broadly, security, comms and exception management.

You deploy these things on desktops, phones, and devices. Other parts of the things live on servers or on clusters, mabe. Call these places (hardware) tiers.

There. Architecture done. From micro services to huge banking monoliths. Start there. Everything else is the usual let's think about what we're doing before we do it.

But I guess keeping it simple and dealing with exceptions as they arise isn't as glamorous as using fancy new names, working for a hipster consultancy or generally saying X or Y is teh new futures.

If you harbour doubt great, questions are good. I suggest obtaining a copy of Wicked Problems, Rightous Solutions (ISBN-10: 013590126X). It will show you that we had EXACTLY the same problems of today, back in 1990. We just call them new things.

<comment><USER29> Fancy new names is basically the antithesis of Fowler's approach (it's driving shared language/canonical definitions).

And personally in the mid-2000s I found Fowler's material to, contrary to your assertions/experience, actually be a source of simplicity (by at least explaining pros/cons/alternatives in a comprehensive/vendor/platform agnostic manner) vs the other "just run this huge EJB server, np!" approaches there were mainstream at the time (and personally who I think would be a better target of your ire than Fowler and ThoughtWorks).

<comment><USER30> I have what I feel like are cultural disagreements with Fowler (e.g. "Enterprise Architecture" is oxymoronic to me) so adjust for my bias accordingly. But perhaps his most famous book is "Refactoring", where he gives (fancy, new) names to things he found in the wild. It's basically what he does and arguably his most influential contribution to the industry.

</comment></comment></comment><comment><USER31> Architecture is your chance to decide which problems will be easy and which problems will be hard.

In a microservice architecture, failure handling is easy. State management is hard.

In a centralized database architecture, failure handling is hard. State management is easy.

<comment><USER32> > In a microservice architecture, failure handling is easy

I'm not sure I would agree with this - it's still incredibly hard to be able to make the rest of your architecture do something useful when a significant part of it goes away. Multiply the possibility of one of your important services going down by the number of important services you have...

</comment></comment><comment><USER33> The author's statement that "My view is that applications are a social construction" I think hints at a deeper truth, that while _code_ is run by machines, managing a _codebase_ is more like raising a plant in a garden and not like changing the oil in a machine. Reminds me of "A Codebase is An Organism"[1].

[1] [https://meltingasphalt.com/a-codebase-is-an- organism/](https://meltingasphalt.com/a-codebase-is-an-organism/)

<comment><USER34> See also: Conway's Law.

[http://melconway.com/Home/Conways_Law.html](http://melconway.com/Home/Conways_Law.html)

</comment></comment><comment><USER9> Whenever I see yet another article by Martin Fowler, Kent Beck, Robert Martin & co I ask myself - where is the evidence for what they are preaching? What are the graphs based on? What is the evidence behind the proposed rules?

These authors are clearly accomplished blog and book writers, but anyone whose _software-related_ accomplishments are not open source or at least well known should have their statements scrutinized more closely.

I don't see any studies cited, case studies presented or concrete examples. All I see is yet another reasonably sounding yet unsupported piece of folklore.

<comment><USER35> For some of these speakers, I've literally never seen any evidence that they've written a single line of code. Why should we listen to Fowler? What large successful projects has he created using his ideas are there that I can look at? Where's the data behind his slides? It's all just talk talk talk.

I'd listen to someone like Chris Lattner talk about how to design and write software because I can see whatever approach he uses must work well. I should listen to these full-time speakers because... I don't really know and perhaps we should start challenging their talks by asking for the data behind them.

<comment><USER36> Chris Lattner knows how to write system software and compilers which are completely separate beasts from the typical bespoke enterprise or software as a service apps that most developers write every day.

<comment><USER37> Exactly, many times these famous authors advocate for practices that make sense for building compilers and frameworks or libraries, but that make little sense for building applications.

Building applications is very different, because an application is the very end of the software tree dependency. Some practices make sense for both types of software, but many others don't and some of these authors don't seem to be able to make the difference.

<comment><USER36> And sometimes it makes sense to take shortcuts that don't make sense from a long term maintenance standpoint just to survive long enough to get product market fit. Get funding and survive.

Twitter is a perfect example of this. Everyone agrees that Twitter made some bad architectural decisions that caused the frequent appearance of the "fail whale". But eventually, they got enough funding via combination of the VC funding and later the public market to rearchitect their system.

</comment></comment></comment></comment></comment><comment><USER38> His biggest contribution may be the documentation and defining the vocabulary, but when he defines a pattern with a word that has an obvious negative connotation ("anemic"), it feels manipulative.

A while ago I was told by members of a separate team that I was writing the core of my javascript application incorrectly. I was following "functional core, imperative shell"[1] and intentionally separating my data from my functions[2]. Specifically, the code was considered to be wrong because it was "anemic", and I was sent a link straight to that 16 year old page about anemic domain models[3]. The suggestion to fix was to add a bunch of mutable state.

Don't get me wrong - I still almost always appreciate Martin Fowler's writing, as it's often quite good, including the original post. But I also understand some of the skepticism here.

\---

1: [https://www.destroyallsoftware.com/screencasts/catalog/funct...](https://www.destroyallsoftware.com/screencasts/catalog/functional- core-imperative-shell)

2: [https://softwareengineering.stackexchange.com/q/203077](https://softwareengineering.stackexchange.com/q/203077)

3: [https://martinfowler.com/bliki/AnemicDomainModel.html](https://martinfowler.com/bliki/AnemicDomainModel.html)

<comment><USER39> I think that's a case of misguided developers with tunnel vision misusing Fowler's material.

I have never met Fowler and I'm completely speculating here, but I would bet money he is both well-versed in, and a big fan of, the "functional core, imperative shell" concept when it is a good fit.

Devs often get overly dogmatic, and when they do, they often reach for Fowler quotes to back themselves up. But don't blame Fowler for that.

</comment></comment><comment><USER40> Let's talk about any good parts.

The architecture of systems varies enough that there isn't a good concrete definition. An aspect that's important for one system isn't for another so it's hard to say which aspects are part of an architecture. Unless you're always architecting the same types of systems, this will carry some weight.

The other idea that architecture is present but not visible is a great one. It's the important bits that are underlying or overarching or otherwise permeates the system without necessarily being separately visible. I've had so many difficult chats talking past one another about different levels of concern. When one side only sees what's named or in the diffs, it's hard to convey why something else is more important when there's a lack of 'shared understanding'.

I did have this experience when I was making a relay service which handled a headless browser and audio streams. Each of these ended up using a state machine so I separated the state machine mechanics and implemented each using it. The result ended up having many state machine visible parts than the interesting (for the use-case) non-state-machine parts. I undid all that and made each back to primarily do its job as a state-machine but it was far less visible. This isn't the best of examples but it's one where I learned that sometimes you want things to be less invisible even when it's important.

</comment><comment><USER41> Martin Fowler: "Architecture is hard to define, but I'll try. Good architecture allows the system to evolve. Bad architecture attracts cruft and makes change hard."

HN: "Fuck this ivory tower bullshit! Where's the evidence?!?!"

<comment><USER42> My objection is the "ivory-tower bullshit" is wrong.

He goes to pains to fail to define architecture and rejects a reasonable definition for a confused genetic fallacy about social construction.

"Architecture" isn't _understanding_. Understanding is _of_ Architecture. If architecture were merely "the common understanding of what's important" there could be no disagreement or understanding of the software. Disagreement would be hopelessly social: you could never say "this is too complex", but only, "your understanding is wrong".

> "My view is that applications are a social construction"

Deeply confuses many issues. Applications are made by people, as are tables, but neither are "social constructs" \-- which mean they are irreducibly subjective group phenomenon.

Software runs on machines. The running machine isn't a subjective group phenomenon. "1 + 2" is code, mathematics isn't a "social construct".

"Architecture" refers to the structural elements of a domain (ie., how the domain objects are related to each other, and how these relations are related to each other, etc.).

It is a relative term, but not a subjective one. eg., The "architecture" of a animal is how its parts fit together. The "architecture" of a leg is _its_ pieces fit together. And so on.

<comment><USER43> Mathematics is totally a social construct. The UR patterns of our reality are immutable and await discovery. The ways in which humans explain their mathematical observations to each other is via a set of symbols that are socially agreed upon.

My problem with mathematical syntax is that it is so esoteric and arbitrary that many people struggle to use math to communicate with each other. Delving deeper into mathematics is an exercise in learning new symbols and their contexts. The understanding, acceptance, and advancement of mathematical concepts happens through social consensus.

For example, what does K mean? In an equation, strictly speaking it is a variable. But sometimes its a reserved constant. Others, its a unit. Is math 'universal' if the language of math is largely Eurocentric? In fact, several fundamental math ideas emerged from China far before they were expressed in Western culture. Their syntax differed from Western syntax to express largely, but not entirely, the same concepts.

Brett Victor[1] describes how the development of mathematical notation unleashed a clearer level of thinking, and a flowering of mathematical ideas, proofs, and science to follow. This requires agreement... consensus.

Take a look at Wikipedia's History of Mathematical notation and see what smells of culture you can find. [2]

Mathematics is the practice of translating observations about real-world things or abstract ideas from one person to another or many. A smart animal or intrepid alien sentience would not be guaranteed to understand what 3, 3%, or 3º means to us, but they could certainly understand 3 bananas vs 2, or a portion of a whole, or rotation.

Code is a social construct that is well-documented. Developers give trust to language authors and their compilers to generate correct bytecode. They in turn trust systems engineers to interpret their instructions correctly, and so on. Of course there are arguments and different perspectives on what the best way there is to express everything. These things get hashed out on this very social platform, and many others.

Architecture is about imposing one's will on the act of creating long-lived artifacts. It isn't system engineering. Its about arguing that things ought to be built out of arches, because they are durable, and look interesting, and especially because they have a rich symbolism associated with passage into new time and space. The will of an architect is usually something like enduring harmony with its inhabitants and surroundings. Software architecture I feel attempts to create durable systems for people to inhabit with their knowledge, and that is as social as it gets.

Sure, you may think of a software architecture as a formalized design on how to stitch together bits of data across network boundaries, maybe using packaged services from Cloud vendors. It is, but good architecture accounts for who is building it and who will own it, use it, and maintain it. It makes sure information isn't lost and people's simultaneous actions don't result in collisions. It attempts to resist loss, against a wide variety of classes of threats.

Look, I've been intrigued by event-sourcing, and also have heard of lots of gnarly consequences of trying to adopt it. Like any other pattern, its mileage may vary depending on the problem domain. An "ivory-tower bullshit" pattern may be widely a considered a "wrong" practice for the domains of today, but that doesn't mean you can prove that its fundamentally invalid in all cases.

If software architects made blueprints, I would think of the work of making said blueprint is "architecture". the work of software architecture is social, considering the needs of users, developers, and its financiers. What I read in your comment is referring to the blueprint as "architecture", or an architecture. Whatever the artifact of software architecture work is, the work itself is equal parts social and technical, and always in the context of the raw materials available at the time.

[1] Brett Victor, The Humane Representation of Thought [https://vimeo.com/115154289](https://vimeo.com/115154289) [2] [https://en.wikipedia.org/wiki/History_of_mathematical_notati...](https://en.wikipedia.org/wiki/History_of_mathematical_notation)

<comment><USER42> You have to separate social-subjective elements from individually-subjective elements from objective elements.

The objective elements are, simply put, "what is true _of_ the object". And the subjective elements are "what is true _of_ the subject.

Where "object" is the _target_ of understanding, and "subject" is the "understander" \-- ie., not the human (as holding organs) but the human (as holding experiences).

When I say, "the code has 100 lines" that is _true_ in virtue of the object. It is _meaningful_ in virtue of various conventions about what a "line" is and what "code" is.

Let's not confuse _what is being said_ for _how it is said_. The latter is subject-relative, the former is object-relative (ie., objective).

Mathematics is _about_ order. The target of mathematical description is objective (it is instanced by objects, not by experiences). However _mathematics_ as a language is conventional (ie., social-subjective).

 _What is being said_ (eg., that there are infinitely many primes) can be said many ways. Each of those ways is only _meaningful_ given a social background.

Likewise, "Architecture" is a term grouping together some -- but not all -- facts _about_ software. (eg., inheritance dependencies, but not comment symbol choice). _What is being said_ requires _conventions in which to say it_.

OP article seems to confuse these issues mightily and I think would impair someone looking to understand "architecture" without prior experience. It _is not_ merely "what's important". Many things are important.

</comment></comment></comment></comment><comment><USER44> The key to understanding Fowler and similar, and Thoughtworks, that the methodology _is_ their product. They sell consulting and training and seminars and conferences and books.

If any useful, working software is produced that is at best by sheer coincidence and more likely _despite_ their involvement.

</comment><comment><USER45> We see that Martin Fowler is influenced by Ralph Johnson in deriving for himself a definition of architecture. In particular,

 _there was no objective way to define what was fundamental, or high level_

And goes on to lean heavily on the idea that 'application architecture' is a social construct. But I am then left with a thought that if application architecture is a social construct, that means there should be identifiable social characteristics that make-up the application architecture, characteristics that can be further quantified to an acceptable degree, such that they can be defined as fundamental.

Taking a step back from Martin's influence & conclusion, and ask ourselves, "couldn't software architecture, or architecture in general, be defined by a set of heuristics that lead to objectively defining what is fundamental to a particular context?"

Suppose we create three rules that need to be defined before reaching our conclusion:

\- context: what scale does the architecture in question reference?

\- collection of computing elements: what are the computing elements (this can range from machines to software)

\- connectedness: how are the computing elements connected?

For example, in order to determine the architecture of my web scraping local machine setup I would go through the rules:

\- context: a single script file with code written to accomplish the task

\- collection: functions that are used to perform the task of scraping the webpage

\- connectedness: functions pass data to other functions to perform specific tasks of scraping

In this example we have a guide to achieve objectively what is fundamental to our architecture.

</comment><comment><USER46> I start with a raw stone, and carve away the crud ... then I bring the duct- tape ...

</comment><comment><USER47> Would it help if instead of software "architecture," we called in software "organization?" It seems like nobody would demand "proof" if Martin was arguing that it is faster and easier to find a book in a library than it is to find a book at the dump.

</comment><comment><USER48> I started reading his sample chapter on refactoring and I'm constantly put off by some really rookie mistakes and bad code practices like naming a function after nouns instead of action verbs (e.g. "amountFor" instead of "computeAmount").

</comment><comment><USER49> _Head closer to the rocks of chaos rather than suffocating control. But being on that side of the channel still means we have to avoid the rocks, and a way to maximize local decision making in a way that minimizes the real costs involved._ \- Martin Fowler

... added to [https://github.com/globalcitizen/taoup](https://github.com/globalcitizen/taoup)

</comment><comment><USER50> The only thing missing is Martin Fowler having his own vlog

</comment><comment><USER51> Lovers gonna love, haters gonna hate.

</comment><comment><USER52> Unusually useless post. An aggregator that says little. Too bad.

<comment><USER53> I would really like to read through a solid post that details Enterprise Software Architecture. As the author mentions, it certainly is hazy and I wonder if you can bring in 2 architects form different firms to talk the same language.

Wonder if HN has a recommendation.

<comment><USER54> Not an article, but a book:

"Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solution" by Hohpe and Woolf

(You don't need to read all the patterns in detail; reading the overview will be enough to get you a pretty good idea. You only need to read the details when you seriously consider implementing a pattern).</comment></comment></comment>


XBMC For Android - <AUTHOR> http://xbmc.org/theuni/2012/07/13/xbmc-for-android/ <comment><USER2> > Currently, for most devices only software decode of audio and video is > hooked up.

This is a good start, but ultimately, you _need_ hardware decoding. Even if a modern phone or tablet could decode 720p x264 in real time (many cannot), the battery usage would make it entirely untenable.

<comment><USER3> Is there a list of devices that currently have hardware decoding supported?

<comment><USER4> The article talks about the Pivos box already, it's supposed to be (check first!) this one:

<http://www.amazon.com/gp/product/B0088IGPM8>

Not affiliated, no experience with that thing, but I think that's the only device with hardware decoding support as stated by the article.

</comment></comment></comment><comment><USER5> Ouya makes Android a major gaming platform and XBMC will make it a dedicated media center. Android it truly realizing its true potential.

<comment><USER6> "makes": Ouya doesn't exist yet.[1]

"will make": XBMC is here now, plus has a track record of delivering.

The "true potential" of Android isn't about gaming. Its true potential will be realized when it can run on the disposable pay as you go handsets used by the other 5 billion people on the planet as their primary and only computing device.

1\. "The reality of the OUYA console doesn't match the hype: why you should be skeptical", Penny Arcade, [http://penny-arcade.com/report/editorial- article/the-reality...](http://penny-arcade.com/report/editorial-article/the- reality-of-the-ouya-console-doesnt-match-the-hype-why-you-should-be-ske)

<comment><USER5> You, me and Penny-Arcade are all subjective.

<comment><USER6> That XBMC exists as a product and Ouya doesn't is not subjective. The GP comment used the wrong verb tense for each. You or me remarking on this objective fact is not subjective either.

The PA Report does indeed contain opinion.

</comment></comment></comment></comment><comment><USER7> For those more knowledgeable than I: would this run on Google TVs? It looks like it's an NDK app, and I was under the impression that GTV didn't support the NDK.

<comment><USER8> If it's an NDK app, then no it won't run. The Logitech Revue (aka Google TV standalone box) has an Intel Atom processor, not an ARM, unlike most every other Android device.

<comment><USER9> Since it is an open source app, couldn't you just compile it yourself? Or maybe drop a friendly suggestion to the devs to release an x86 binary.

<comment><USER10> Two more things:

1\. It might run. APKs support packaging more than one machine architecture for NDK code in one apk. Currently, there is built in support, in the SDK, for both ARM variants and x86. You can get add-on support for MIPS. Possibly others, IDK.

2\. If it doesn't run and you have source access, and if the native code is all in C and C++, you can compile it by adding the option to generate x86 code. It will be packaged in the resulting apk file, and should be installable on Google TV, unless it uses other APIs not available on Google TV.

<comment><USER11> Unfortunately, while the Android NDK supports native code on x86, ARM, and MIPS processors, GoogleTV doesn't support the NDK:

        Does Google TV support NDK?

        No. There is a pending feature request for NDK support on Google TV

        https://developers.google.com/tv/faq#ndk

It is my understanding that the Intel-based mobile phones are the first x86 Android devices to support the NDK.

<comment><USER10> Forgot to check that. Good catch!

</comment></comment></comment></comment></comment></comment><comment><USER12> What about Plex? IIRC it's a fork of XBMC and has been available for both iOS and Android for the last 6 months or so. Nothing against XBMC but Plex is probably a better choice right now if you want something stable.

<comment><USER13> Plex is closed source. An XBMC announcement is more exiting just by virtue of its open and non-proprietary nature.

</comment></comment><comment><USER14> Syncing up with the repo, it will certainly be interesting to see how this runs on the NexusQ that I received from I/O

<comment><USER14> Got it up and running, choppy on the NexusQ but it certainly looks very promising, now to roll up the sleeves and help out

[https://plus.google.com/109944805317147383619/posts/gnzpC8HE...](https://plus.google.com/109944805317147383619/posts/gnzpC8HETpP)

</comment></comment><comment><USER15> This is wonderful news for OUYA preorderers.

</comment><comment><USER16> This should result in another surge of OUYA contributors.

<comment><USER17> This is the primary reason I pre-ordered (which I'm aware is something of gamble). If the OUYA folks are smart, they'll bundle Plex or XBMC.

</comment></comment><comment><USER18> i think this plus the fact that nexus q has been hacked to run apps might be a boon for nexus q.

[1][http://www.engadget.com/2012/07/10/nexus-q-hacked-to- launch-...](http://www.engadget.com/2012/07/10/nexus-q-hacked-to-launch-apps- gets-remote-control-web-app/)

</comment><comment><USER19> Awesome, I've been thinking about building an HTPC, but beginning to balk at the power cost compared to some sort of streaming device and low power storage unit connected over N wifi. If there's box that has spdif out I'll buy it straight away (for high quality DA audio conversion).

<comment><USER20> Check into the ZOTAC Z-Box. The power consumption is pretty decent compared to a full Micro ATX or ITX. It has optical and HDMI audio. Wireless N... I'm running OpenElec on mine and it's very responsive.

</comment></comment><comment><USER21> There's a built APK up on Miniand: <https://www.miniand.com/forums/forums/1/topics/136>

</comment><comment><USER22> Will this work with the Nexus Q? Doesn't seem to work on my HP TouchPad.

<comment><USER23> <http://news.ycombinator.com/item?id=4245370>

</comment></comment><comment><USER24> Remember all of the cheap, hardware decode capable ARM devices we've seen lately?

This is awesome, awesome, awesome. XBMC is an impressive piece of software. uPNP AV/DLNA, AirPlay, can play from every network sharing technology I've ever heard of.

<comment><USER25> I always say that its the best software I've ever used and I've been using it since the OG xbox ~2005. It is perfect for a television and somehow they manage to constantly improve it.

Inexpensive set-top hardware coupled with xbmc is a definite win</comment></comment>


Google Plus: Is This the Social Tool Schools Have Been Waiting For? - <AUTHOR> http://www.readwriteweb.com/archives/google_plus_education.php#.ThCswZ8bxaE.hackernews <comment><USER2> KhanAcademy should immediately try to integrate it with their videos. Kids could learn in groups, and talk about the lesson among themselves in a Hangout while watching the videos. I think it's a nobrainer for KhanAcademy.

But even without the integration, you can still do that with Hangout and using Sal's videos.

</comment><comment><USER3> check out edmodo.com a true social network for educators</comment>


The Loneliest Genius - <AUTHOR> http://nautil.us/issue/19/illusions/the-loneliest-genius

<comment><USER2> There are some doubting the veracity of the article, and while it is onesided in how it paints Newton, the main conclusion, how Newton's childhood might have contributed to his penchant for isolation is a solid one.

Newton was in his time known as vindictive, secretive, paranoid, sensitive (especially to criticism, he would have made many enemies here on HN) and fairly querulous. Throughout his life he had few friends, wasted no time on idling and had no time for art or music. He was puritanical and deeply religious. In his early notebooks he recorded sins such as: _Squirting water on Thy day ' and 'Making pies on Sunday night'_

He was also prone to rages, as recorded in that same notebook:

 _' Striking many'; 'Punching my sister'; 'Wishing death and hoping it to some'._

In [1] it is stated: _Given the rage that Newton had shown throughout his life when criticised, it is not surprising that he flew into an irrational temper directed against Leibniz_ and that _Newton 's assistant Whiston had seen his rage at first hand. He wrote:- 'Newton was of the most fearful, cautious and suspicious temper that I ever knew.'_

However, while these aspects of Newton's personality have recently been the topics of focus in various articles and books, what is often omitted is that Newton was only so vindictive if he felt slighted. Granted, this was not hard to do, but there were other aspects to his character[2]:

 _> He has usually been found to have been an unsmiling and humourless, puritanical man with a countenance that was 'ordinarily melancholy and thoughtfull', but which, as Henry More FRS (1614–87) described during a discussion about biblical prophecy, could sometimes become 'mighty lightsome and chearfull, and in a maner transported.'20_

 _> He always kept Close to his Studyes, very rarely went a visiting, & had as few Visitors, ...excepting 2 or 3 Persons… in whose Company he took much Delight and Pleasure at an Evening...I never knew him take any Recreation or Pastime, either in Riding out to take ye Air, Walking, bowling, or any other Exercise whatever, Thinking all Hours lost, yt was not spent in his Studyes_

Newton grew up with what seems to be have been a rather disturbed childhood. Isolated, with indication of having been distant to his mother (at least early on) and mistreated by his stepfather; when coupled with how far ahead he was when compared to his peers†, seems to have resulted in an emotionally stunted, insecure and sensitive individual. Taken together with his obsession with righteousness, it is not hard to see how he might have been difficult to get along with, in turn feeding back to poor social ability and bolstering his inclinations towards being alone.

Newton seemed to have suffered from depression and poor self image throughout his life, exacerbated no doubt, to paranoid delusions later on by consumption of heavy metals as mercury, arsenic and lead.

Certainly Newton was not an easy person to deal with; his brilliance, lack of interests and religiosity coupled with insecurity and pensive nature made for a difficult combination to not somehow run afoul of. He was likely not one to suffer fools lightly and was probably very good at holding a grudge. There are signs that he would have been pedantic and insufferable, the servants at his home certainly had no kind words to lay on him. Yet in the context of his early abandonment, the antagonism of his household against his bookishness, the hostility of his stepfather and the isolated childhood from having grown up with a mind so blazingly sharp, it is difficult to fault him for ending up as one so prone to churlishness. But despite a tendency towards a dour disposition, _Stukeley wrote of him in his Memoir:

"according to my own observation, tho'. Sr. Isaac was of a very serious, & compos'd frame of mind yet I have often seen him laugh, & that upon moderate occasions. he had in his disposition, a natural pleasantness of temper, & much good nature, very distant from moroseness, attended neither with gayety nor levity. he usd a good many [shrewd] sayings, bordering on joke, & wit. in company he behavd very agreably; courteous, affable, he was easily made to smile, if not to laugh."_

† _Stukeley later wrote: one reason why Sr. Isaac did not play much with his schoolfellows, was, that generally, they were not very affectionate toward him. he was commonly too cunning for them in every thing. they were sensible, that he had more ingenuity than they_

[1] [http://www-history.mcs.st-and.ac.uk/Biographies/Newton.html](http://www- history.mcs.st-and.ac.uk/Biographies/Newton.html)

[2] [http://rsnr.royalsocietypublishing.org/content/62/3/289.full](http://rsnr.royalsocietypublishing.org/content/62/3/289.full)

[http://www.newtonproject.sussex.ac.uk/prism.php?id=40](http://www.newtonproject.sussex.ac.uk/prism.php?id=40)

</comment><comment><USER3> Did Newton himself ever complain about loneliness? I 've never heard anything of the sort, yet this writer assumes it.

Try to picture the genius of Newton in the dark ages in which he lived. He found patterns and understood the world in astonishing ways. I think it was genuinely impossible for him to find a soulmate other than himself, even among his educated peers. He found patterns and understood the world in a profoundly different way than others. Should we not assume he was happy with discovering the unimaginable? Is that even comparable to the petty joy of socializing?

<comment><USER4> >Should we not assume he was happy with discovering the unimaginable?

He had nervous breakdowns, one of the causes: chronic psychological depression

<comment><USER3> His nervous breakdowns were attributed to ingestion of chemical substances (he was experimenting with alchemy) [http://en.wikipedia.org/wiki/Later_life_of_Isaac_Newton#1693](http://en.wikipedia.org/wiki/Later_life_of_Isaac_Newton#1693)

</comment></comment></comment><comment><USER5> _If his retreat into the realm of the mind was a boon for science, however, it came at a great cost to the man, and seems to have been connected to the loneliness and pain of his childhood._

I wonder if OP is confusing cause and effect. Did his choice of solitude cause him to suffer socially or did his decision to not waste time with others on minutiae enable him to focus on what he thought was more important? I prefer to choose the latter (for Newton and myself).

<comment><USER6> Do you really think time spent being social is wasted?

No judgement, just curiosity.

<comment><USER7> Here's something to consider.

Being lonely by myself hurts. Being lonely in a group of people hurts more. Learning about algebraic topology doesn't hurt.

I think it's a bad idea for people to be by themselves, but I can more than empathize with the "I would rather not" sentiment in this thread.

<comment><USER8> If I feel lonely and isolated, I am less inclined to be creative. If I am healthy and socially active, I feel more motivated to work harder and create.

I have wasted so much while being alone and while being very social. It's a vicious thing but all I can do is improve my habits and seek out balance.

</comment></comment></comment></comment><comment><USER9> Sorry for the off topic.

> like convincing cats to gather for a game of Scrabble

If you get any board game out in a house with cats, it will be minutes until they are all gathered, trying to sit on the board. Perhaps they should have said "like convincing cats to not sit on a game of Scrabble".

</comment><comment><USER10> What about Newtons later career where he made the unlikely transformation from scientific genius to stupendous badass?

 _" Counterfeiting was high treason, punishable by the felon's being hanged, drawn and quartered. Despite this, convicting even the most flagrant criminals could be extremely difficult. However, Newton proved to be equal to the task. Disguised as a habitué of bars and taverns, he gathered much of that evidence himself. For all the barriers placed to prosecution, and separating the branches of government, English law still had ancient and formidable customs of authority. Newton had himself made a justice of the peace in all the home counties"_

[http://en.wikipedia.org/wiki/Isaac_Newton#Later_life](http://en.wikipedia.org/wiki/Isaac_Newton#Later_life)

For an heavily fictionalized, but hugely entertaining, account of the times, I can _strongly_ recommend the Baroque Cycle - much stupendous badassery.

</comment><comment><USER11> "When Sir Isaac Newton died in 1727, he left behind no will and an enormous stack of papers. His surviving correspondences, notes, and manuscripts contain an estimated 10 million words, enough to fill up roughly 150 novel-length books."

[http://www.wired.com/2014/05/newton-papers-q- and-a/](http://www.wired.com/2014/05/newton-papers-q-and-a/)

Those words are being transcribed and published. You can read what is published so far here:

[http://www.newtonproject.sussex.ac.uk/prism.php?id=1](http://www.newtonproject.sussex.ac.uk/prism.php?id=1)

</comment><comment><USER12> Warning - this is an excerpt. The full article appears to require a subscription.

<comment><USER13> Giant paywall. I was bummed, great article so far.

<comment><USER14> Me too. Fortunately the solution was trivial. I bought a subscription.

</comment></comment></comment><comment><USER15> It reads like a character assassination. A very negative interpretation for no particular reason, and a highly incredulous and begrudging perspective of the extreme introverted or loner character.

A truly _awful_ article.

</comment><comment><USER16> I feel skeptical to read about history of anything or anyone. People are complex entities. We have rational and emotional/irrational habits/reactions ...etc. Generally, historians look at the documents left or recorded and construct some picture. But I feel, no one or no entity records every emotion, every reaction, every action they do or involve ...etc. So there will always gaps/holes and there will always be unknown unknowns. Sometimes, we feel, we reached conclusions and may be awards are given and after few years, some new leads open up and it may change whatever we know till then making us feel like fools to trust in the beginning. Then there are many, who won't record anything, no trace at all. We are around 7 billion people now approximately and how much we record daily about ourselves for _others i.e. future historians_? I feel recording for future historians is overhead. Writing diary for yourself is different thing altogether.

So in conclusion, please do not conclude whatever you read as final w.r.t history even though it may be detailed or how well it may be written. There are always unknown unknowns.

Take whatever useful in your life and leave the rest may be the optimal approach towards history, if really required. Otherwise, in general scenario i.e. for daily life, just ignore history.

</comment><comment><USER17> Is it just me or is it Newton season? Aeon Magazine recently ran an article on magical thinking that mentioned Newton, and I swear I've seen him mentioned in other articles recently as well.

<comment><USER18> Actually, it is - literally. As the article mentioned, Newton was born on 25th December, so he often comes up in Christmas-related discussion and so this time of year is a good time to mention him.

[https://www.google.co.uk/search?q=newtonmas](https://www.google.co.uk/search?q=newtonmas)

</comment></comment><comment><USER19> Some of the paragraphs, ie. the first and second, are really good. Some others, aren't.

>Physicist Richard Feynman voiced the feelings of many a self-absorbed scientist when he wrote a book titled, What Do You Care What Other People Think?

Did he? I finished the book a few days ago, and there aren't really anything self-absorbed about it.

>Newton never wrote a memoir, but if he had, he probably would have called it I Hope I Really Pissed You Off, or maybe, Don't Bother Me, You Ass.

What does this even mean? From the article itself, it sounds like Newton didn't want to socialize, not that he wanted to piss people off.

>He had come into the world on December 25, 1642, like one of those Christmas gifts you hadn't put on your list.

I.. what? Surely, for a parent to get his/her child is a present indeed. (I might misread this, but gifts I don't put on my list are gifts I do not want!).

>They certainly weren't close—in all the writings and scribbles Isaac left behind there is not a single affectionate recollection of her.

The fact that there aren't anything doesn't mean they weren't close (one can be close without expressing it in writing!).

>The lonely but intensely creative life he led as a boy was preparation for the creative but tortured and isolated life he would lead for most—though happily not all—of his adult life.

The author seems to assume that everyone have to be surrounded by people to not have a 'tortured life'. I can't really say I agree.

>But Newton was not cut out to be a farmer, proving that you can be a genius at calculating the orbits of the planets, and a total klutz when it comes to growing alfalfa. What's more, he didn't care.

It sounds indeed like he didn't care, not that he simply sucked at it (though he might did suck).

All in all, I'm not sure I liked the article in its entirety. Somehow, the author thinks (or knows, but without backing it up) that Newton was a bitter, arrogant misanthropy, because of a bad childhood.

<comment><USER20> I think the writer meant that the gift is one that you didn't ask for, but realize that it is a great thing. Nobody asked for Newtonian Physics, but he delivered it and greatly improved our understanding of our world.

<comment><USER21> This doesnt really matter :) but.. They wrote that he was born early, his early birth coincided with christmas hence unexpected gift At least thats how i read it</comment></comment></comment>


Why NPR is Thriving (They're Not Afraid of Digital Media) - <AUTHOR> http://www.ikiw.org/2009/04/25/why-npr-is-thriving-theyre-not-afraid-of-digital-media/ <comment><USER2> I'd imagine the government subsidies and not needing to pay for their chunk of the FM spectrum probably have a lot to do with it, too.

<comment><USER3> The subsidies are quite low, actually. NPR itself only gets between 1-2% of its funding from the government.

Member stations average about 11% from the Corporation for Public Broadcasting, which is government funded. The rest comes from listeners during those annoying, but necessary pledge drives, private grants, and corporate sponsorship (and I can tell you from experience, they place _a lot_ of constraints on what they'll say in that underwriting spot you pay for).

Details here: <http://www.npr.org/about/privatesupport.html>

<comment><USER4> This is blatantly false, for reasons I'll explain below.

Also, you're conflating NPR (NPR, Inc.) with member stations. These are different entities.

The topic is NPR.

The numbers that you cite are not numbers for NPR.

They are not even number for NPR member stations.

They are aggregate numbers for public broadcasting stations ... _including those not affiliated with NPR_.

Getting the truth out of NPR's reports can be tricky. They haven't filed an annual report in four years, and the financials are split up between NPR, Inc., the NPR foundation, the CPB, and various member stations. You have to read a LOT of documents to figure out some of this stuff.

Let's start with NPR's financial documents.

       http://www.npr.org/about/statements/fy2008/fy08nprincreport.pdf

I note $2.5 million in membership dues (individual donations) out of $172 mill total. Thus, individual subscribers and pledges make up 1.45% of NPR's budget.

$68 million comes from station programming fees. What are these? These are fees that local affiliates pay to National Public Radio, Inc. Where do those dollars come from? A typical affiliate gets two thirds or more of its budget from the Corporation for Public Broadcasting. The CPB is a shell corporation / funnel that connects federal dollars to NPR with a cut-out step. See the CPB financials here:

      http://www.cpb.org/aboutcpb/financials/budget/

The CPB gets $400 million per year from taxes, takes 10% off the top for operations, and funnels 90% of the money to local affiliates, which then funnel most of the money back to NPR.

The data that you cite about the sources of funding are not for typical NPR affiliate stations: first, it includes many stations that aren't NPR stations, then it excludes many stations that _are_ NPR stations (they mention this in a footnote).

Where else does NPR get its revenue? Grants, contributions, and sponsorships total $52 mill. Let's be generous and say that half of that comes from private sources (in fact, most of these grants are coming from other government funded organizations).

A big contributions to NPR's top line is from the NPR Foundation, which gave 15 mill in 2008. ...but look back at the 2005 numbers, and it was just 1.7 mill. Why the huge (1,000 %) increase in money from the NPR foundation? Read the NPR Foundation's reports and the Consolidated reports

       http://www.npr.org/about/statements/fy2008/fy08nprfoundationreport.pdf

       http://www.npr.org/about/statements/fy2008/fy08consolidatedreport.pdf

and you can see that _they've been investing in highly leveraged hedge funds and interest rate swap contracts these past few years. To put it mildly, this doesn't look like sustainable money._

Putting aside the non-sustainable NPR Foundation money, the federal government makes up $90 mill of NPR's after-removing-the-Foundation revenues of $152 mill.

So, where does NPR get its money?

* federal dollars: 60%

* individual contributions: 1.5%

* advertising, misc: 38.5%

<comment><USER5> _A typical affiliate gets two thirds or more of its budget from the Corporation for Public Broadcasting_

Can you source this statement? My local affiliate, for example, is 63% funded by individual contributions.

Not that I disagree with the overall point - organisations that are publically funded (NPR, BBC, CBC, etc) are more likely to put their IP out there for everybody and to do non-sexy reporting. I see this as an entirely good thing and possibly one of the best uses that my tax money is put to.

</comment></comment></comment></comment><comment><USER6> The interesting point for me here is NPR's revenue model. They're supported by tasteful sponsorships and donations, and they give their content away. They're more successful at this model than any website that I can think of.

They are the one traditional news outlet that isn't damaged by changes in distribution methods. The only change might be that they need to spread their pledge drives out more broadly so that it's harder to skip or tune out.

<comment><USER4> > They're supported by tasteful sponsorships and donations

They get 50% of their budget from taxes, and most of the "tasteful sponsorships" are large companies that either get large subsidies from the overnment, or work under lots of government regulation and want to buy favor with congress.

The largest sponsor of NPR is Archer Daniels Midland, an agricultural corporation. Want to know why Scientific American is talking about how food shortages could kill tens of millions over the next few years?

[http://www.sciam.com/article.cfm?id=civilization-food- shorta...](http://www.sciam.com/article.cfm?id=civilization-food- shortages&page=4)

It's because ADM has been using its NPR sponsorship to buy access in Washington, where it can push biofuel mandates, turning food into a poor substitute for gasoline, thus boosting the price of it beyond the reach of the global poor.

</comment></comment><comment><USER7> Is someone in an alternate universe? From Friday's NY Times:

"In a new round of cost-cutting, National Public Radio said it would lay off 13 employees, eliminate contributions to employee retirement accounts for the rest of fiscal 2009 and impose five days of furloughs for all employees before the fiscal year ends on Sept. 30."

No one--not even NPR can monetize their audience to pay for programming. Programs like "All Things Considered" and "Prairie Home Companion" are dependent on an expensive infrastructure and staff.

I work in 'old media' and the problem for businesses and employees alike is an eyeball on the Internet is worth less money than an eyeball on TV or ears on radio. As we move people to our websites we do so at our own peril. We can afford to produce less for an Internet than TV viewer.

I am no Rupert Murdoch fan, but he put it best when he pointed out ad space on the Internet is unlimited. Therefore there will always be downward pressure on advertising rates.

In the short term this isn't a big deal for end users. In the long run people will realize much of the news and entertainment programming we all enjoy (not all and not necessarily the best) will no longer be produced.

<comment><USER8> Billboard space in our universe is unlimited (in the same sense as ad space on the Internet is unlimited) as well. Not all locations are equal, and hence there will be competition for the best locations.

</comment></comment><comment><USER9> NPR may be "thriving" in terms of audience size, but just a few months ago they canceled a show and announced layoffs due to a lack of funds.

</comment><comment><USER10> NPR is thriving because it manages to be the best information source in any medium. It's not the economist, but it's informative, entertaining, cultured yet very humane. The Saturday programming alone forces me out of bed early; Weekend Edition, Car Talk, Wait Wait Don't Tell Me, This American Life, Studio 360, Market Place, On the Media and All Things Considered. You just can't find that anywhere.

TV and regular media have no chance. Commercial FM radio is just obnoxious and loud. I'm shocked and offended every time I get my car back from a borrowing relative and have the preset on some loud annoying jockey. American television .. best left unsubscribed to. Its best hours are 5PM to 9PM of the Sunday Fox programming; when it shows animated shows, which can now easily be watched on Hulu.

For those of you who read the Economist, I can recommend Mother Jones to balance out the right-wing nuttjobery that pervades the otherwise excellent publication.

</comment><comment><USER11> Is NPR really considered "mainstream-media"?

To me "mainstream-media" means the big for-profit corporate conglomerates.

I bet not needing to make a 10-15% profit has much to do with it. Not only monetarily but also integrity("no worries a show/statement will alienate advertisers") and public perception. In fact I'd wager the not afraid of digital is a symptom of being a NPO.

</comment><comment><USER12> NPR makes up about 50% of the podcasts I listen to. I've been able to plug my ipod into my car for 4 years now. I never listen to the radio (music or talk) at all any more.

I mostly listen to Science Friday. They're constantly pushing alternative interaction methods, like second life and twitter. I always figured it was an attempt to engage 'the kids' into science.

</comment><comment><USER9> Also, they're not afraid of getting replaced in a shareholders' revolt.

</comment><comment><USER13> arrgghh the graphics hurt my brain... memo to self: gotta stop reading tufte</comment>


MondlyAR – First Language Learning App - <AUTHOR> https://www.mondly.com/ar <comment><USER2> Nice! the first time I've seen speech recognition used properly in augmented reality</comment>


Docker Announces Orchestration for Multi-Container Distributed Apps - <AUTHOR> http://blog.docker.com/2014/12/docker-announces-orchestration-for-multi-container-distributed-apps

<comment><USER2> Discussion at [https://news.ycombinator.com/item?id=8699957](https://news.ycombinator.com/item?id=8699957)</comment>


USS Robin – A Victorious U.S. Carrier That Didn't Exist - <AUTHOR> http://www.armchairgeneral.com/uss-robin-the-victorious-u-s-carrier-that-didnt-exist.htm <comment><USER2> A slightly different take on British armoured decks in WW2 (it's in the comments) [http://www.navweaps.com/index_tech/tech-030.htm](http://www.navweaps.com/index_tech/tech-030.htm)

</comment><comment><USER3> "it was code-named "Robin" for communication purposes, an intentional reference to the famous—or infamous—English outlaw Robin Hood"

Aw, dang, and I thought it was because the Saratoga was Batman.

</comment><comment><USER4> I expected some story of deception, very interesting story, but I was a bit disappointed.

<comment><USER5> It was a deception, in that the whole thing was constructed to make the Japanese think the USN had one more operational heavy carrier than they actually did.

<comment><USER4> But there literally was another carrier. They stated it openly flew the Union Jack too. It's not really a deception if there is real live carrier right there flying US planes.

<comment><USER5> It is if the Japanese believe the carrier is more powerful than it actually is. See my other reply.

Edit:

WRT the statement about the Union Jack, the jig would be up if the Japanese actually launched an air strike against the task force since the strike pilots would get close enough to clearly see what ship she actually was. Submarines and recon aircraft, however, would probably not be able to get that close and thus would just report a second, presumably American, carrier.

</comment></comment></comment></comment><comment><USER6> Thanks, I just wasted a whole hour reading this, its comments section, and a variety of Wikipedia'd searches around the subject and offshoots.

Armchair General, indeed!

</comment><comment><USER7> That carrier doesn't look like British carriers. I always thought they had a curved launch ramp while USS carriers have always been a flat deck.

<comment><USER2> Those are more modern carriers that were built/converted in the late 20th century to take Harriers off a ski-jump type ramp, because they were too small for modern jet aircraft. British WW2 aircraft carriers were true flat decks.</comment></comment>


Who pollinates the daffodils? (2011) - <AUTHOR> https://honeybeesuite.com/who-pollinates-the-daffodils/ <comment><USER2> I live in an area that during the war, we had to dig up the fieldstairs of daffodils to plan food. Rather than let the daffodil bulbs rot, the farmers planted them in the hedges. So now we have millions of wild daffs. It's beautiful in spring.

</comment><comment><USER3> I used to live in Ireland, and I loved the daffodil season. I still associate daffodils with Ireland. Great memories!</comment>


China's factories in Shenzhen can copy products at breakneck speed - <AUTHOR> http://qz.com/771727/chinas-factories-in-shenzhen-can-copy-products-at-breakneck-speed-and-its-time-for-the-rest-of-the-world-to-get-over-it/?mod=djemlogistics <comment><USER2> [https://news.ycombinator.com/item?id=12724096](https://news.ycombinator.com/item?id=12724096)</comment>


What They Don't Want You to See - <AUTHOR> https://www.youtube.com/watch?v=9HFxVvrXjCg <comment><USER2> Dangerous and false Qanon-type conspiracy theory.

On a more pragmatic level, this is 1:22:17 long, fulfilling the cliche about Q followers giving you hours-long-videos to watch when you ask them for citations. Ha ha, it is to laugh.</comment>