What If Social Networks Just Aren't Profitable? - <AUTHOR> http://powazek.com/posts/3024

<comment><USER2> I think this basic idea is flawed - social networks can be profitable because social networks have been profitable. The vast majority of social networks have not been profitable because the vast majority of startups never reach profitability!

Perhaps a better question (and a more interesting debate) is whether a social network can ever keep up with users and their changing tastes. Myspace was once dominant, but Facebook quickly destroyed it. Digg was once dominant, but Reddit supplanted it. Looking back at the history of the web, there seems to be a point where social networks either fall out of relevance (or muck up a good thing).

Not sure what the answer is to that question...If you look at Myspace, you could argue they died because they failed to change. If you look at Digg, you could just as easily argue that they died because they changed. So, I'd argue that social networks need to stay half a step ahead of their users' tastes to stay profitable. I'm not sure that's possible, so social networks need to diversify (likely away from pure social networking) to stay profitable.

</comment><comment><USER3> The other factor is non-profit open source social networks.

A lot of people like me are determined to popularize open/p2p, distributed or decentralized social networks.

Technically, we're lunch cutting the for-profit networks. But I think both can coexist. However, if open/free networks come to dominate, closed platforms will diminish in popularity.

Search: "Diaspora", "distributed social network"

</comment><comment><USER4> The core conceit here is the idea that what we've seen so far (facebook, g+) represents the apotheosis of social network services. It only takes a few minutes of thinking about that to realize how silly the idea is. Social software is here to stay and it's going to have a big impact on society. But how it works will surely change a great deal over time, to a degree where what exists in 2020 may be completely unrecognizable to us today.

Is social software fundamentally unprofitable? I think the answer has to be no. Even the clumsy monetization of facebook today shows a healthy profit, even if it is orders of magnitude below the fevered expectations of the market. More so, as running high user count services becomes cheaper due to advances in technology social software will merely become easier and easier to profit from.

</comment><comment><USER5> then facebook's investor's are screwed</comment>


The oldest tree in Britain may be switching sex - <AUTHOR> http://mashable.com/2015/11/04/oldest-tree-britain-switching-sex <comment><USER2> I flagged this because the article has little information and drops a lot of loaded terms like "sex switching". Very clearly baiting people into a gender/sex change debate.

<comment><USER3> I don't see why you have to bring this kind of thing into a perfectly fine science story.

<comment><USER2> There was no science! It was a handful of quotes from 2 people...</comment></comment></comment>


15 Problems with Remote Work - <AUTHOR> https://medium.com/@lukethomas14/15-problems-with-remote-work-ccad1471a166 <comment><USER2> All of these issues can be resolved proactively.That being said, the only problem with remote work is that there isn't enough of it.</comment>


Outlook certificate fail - <AUTHOR> https://bofh.zone/2015/10/25/outlook-certificate-fail/ <comment><USER2> We most certainly are checking cert validity. It is possible your cert is self-signed, or from a non trusted CA, or expired.

We also check for secure cipher suites and either fail or prompt the user to accept an insecure connection. We recently deprecated RC4 which caused quite a few support tickets. That could causing your connections to fail.

It sounds like you just got a confusing response from a CS agent (it is a complicated topic). They might be mixing up instructions for IMAP and Exchange which typically runs on 443.

Contact support again and ask them to assign it to Mike from Engineering and I will look into your problem.</comment>


Why are there so few jobs in Rust? - <AUTHOR> https://www.reddit.com/r/rust/comments/e979g0/why_are_there_so_few_jobs_in_rust/ <comment><USER2> I second some of the comments posted there.

I have been following Rust's evolution since its beginnings --as mainly an embedded systems programmer I was acquainted with Cyclone-- and through the years I have tried its different incarnations. The syntax, library support and environment has improved considerably. I have been trying to use it more in my work and personal projects, now that libraries have matured (specially networking and parsers/formatters) and has a better async model which is realtime-friendly. The availability of high level structures like tuples and traits are big time savers, and like Go and Python it can interoperate with C relatively easy.

The issue with the language is that it is an acquired taste. You only appreciate it once you know its history and the problems it is particularly trying to solve. That being said, some design decisions still feel arbitrary or an afterthought, which is annoying.

Most of my colleagues that program in high-level compiled languages and have tried it, hate it. For them it feels like a crippled C++ or Java that is unnecessarily restricted and with too much ad-hoc features ("why do you thought abusing the OR operator for closures was a good idea!"). The other half, which have been programming in C and Assembly (or more esoteric languages like Ada or Erlang) under certified environments for quite some time, are too much invested in those to make a change at this point. They recognize some advantages of the language as nice features to have, but nothing that will fundamentally change their systems programming. And it's another language to learn, track and target tools and libraries...

With more and more stuff moving to the Web and needing more high-level abstractions and becoming further declarative in nature, languages and environments have been getting increasingly polarized. Rust right now is stuck in the lonely middle ground. Perhaps it's just a good general purpose niche language for things that need safety and security like money transactions, and compiling browsers and webassembly applications. The language is still evolving and being actively maintained, thus only time will tell.</comment>


Ask HN: The core values of the Python "platform" - <AUTHOR> Bryan Cantrill gave an interesting talk recently at a Node conference about "platform values" [1]. The talk lead me to think about what the core values of the Python "platform" are and I thought it would be good to ask this question of the community. What would you consider the top (<= 5) core values?<p>[1] http://www.nodesummit.com/videos/?the-video-node2017=45 <comment><USER2> It's all there in PEP 20, but I'll quote my 4 favorites:

> Beautiful is better than ugly.

> Explicit is better than implicit.

> Readability counts.

> There should be one-- and preferably only one --obvious way to do it.

And one more:

> Batteries included

<comment><USER3> I really like this list and would add one more that I think if very important.

Enable Fast iterations

Weather it's a fast loop to test and make changes, or the batteries included mindset that means you can use someone else's code, fast iterations are a big win in the Python world.</comment></comment>


Ask HN: Check out my Canvas based multiplayer Maze - <AUTHOR>

http://www.graphitimaze.com/ I have been working on this for way too long in my free time and I need some outside feedback.  I have tested it in Firefox, Safari, and Opera. Let me know what you think. <comment><AUTHOR> I see you guys running all over the place. Give me some feedback. Is drawing intuitive? Do you wish you could customize your character?</comment>


A deep exploration of the CPython code-base with Philip Guo - <AUTHOR> http://talkpython.fm/episodes/show/22/cpython-internals-and-learning-python-with-pythontutor.com

<comment><USER2> If you haven't read it, Philip's PhD memoir (link: [http://www.pgbovine.net/PhD-memoir.htm](http://www.pgbovine.net/PhD- memoir.htm)) is wonderful.

One of the ideas discussed in it is the importance of knowing your platform. He had an idea for a tool which many other people had before, but it was the deep knowledge of python interpreter that allowed him to create the tool that was actually usable (IncPy).

</comment><comment><USER3> There's a full transcript: [http://talkpython.fm/episodes/transcript/22/cpython- internal...](http://talkpython.fm/episodes/transcript/22/cpython-internals- and-learning-python-with-pythontutor.com)

And the videos from "CPython internals: A ten-hour codewalk through the Python interpreter source code" are here:

[http://pgbovine.net/cpython-internals.htm](http://pgbovine.net/cpython- internals.htm)</comment>


Gombe Chimpanzee War - <AUTHOR> https://en.wikipedia.org/wiki/Gombe_Chimpanzee_War <comment><USER2> Along the same lines (but with a different species) the story of the Mapoogo lion coalition is fascinating

[https://en.wikipedia.org/wiki/Mapogo_lion_coalition](https://en.wikipedia.org/wiki/Mapogo_lion_coalition)

It has been made into a fascinating documentary:

Brothers in Blood: The Lions of Sabi Sand

[https://www.amazon.com/Brothers-Blood-Lions-Sabi- Sand/dp/B07...](https://www.amazon.com/Brothers-Blood-Lions-Sabi- Sand/dp/B079PD1TG9)

(you can also find the video online for free if you search for it)

<comment><USER3> Yes, lots of great clips about lion behavior from BBC and NatGeo on youtube, as well as (mostly nonviolent) scenes captured by safari leaders like Rob the Ranger.

Lions are incredibly savage toward "the other"; no intra-species solidarity seems to exist, though there are incidents of strangers forming coalitions even though they didn't grow up together.

Chimps increasingly are being reported to be somewhat violent and are known to commit murder; cannibalism and rape also are not uncommon.

It's not clear, whether this behavior is continuous throughout their history as a species, or has come to be more common because of the pressure of human encroachment and the reduction in their population. At one time there were millions of chimpanzees in Africa, and today there are maybe 300,000 left in the wild.

</comment></comment><comment><USER4> Chimp and humans have similar levels of outgroup violence, but human ingroup violence is much lower. In wild chimpanzee groups violence or threats of violence are daily occurrence Young chimp males start to beat weakest females daily when they grow enough.

<comment><USER5> In developing countries especially, many parents beat their children daily. Many husbands beat their wives daily. Many teachers beat their students daily. In traffic, motorists and touts engage in fights daily. Governments routinely have their citizens arrested, tortured, and killed. Armed criminals rob, rape and murder people daily. Most babies have their private parts mutilated.

All or most of the above would be classified as in-group violence by an objective observer, so it is difficult to agree with you that our ingroup violence as a species is much lower.

<comment><USER6> Unless you have some source, I think the "developing countries especially" affirmation is unfounded. This happens too frequently in all countries, developed or not.

<comment><USER5> If you are right, that makes my point even stronger, doesn't it?

Do you think I am being downvoted for saying we have a lot of ingroup violence or for suggesting there is more ingroup violence in developing countries? These seem to be uncontroversial points.

I live in Nigeria. Children get beaten here. From their media, I know it's the same in other African countries, India, etc. Everyone accepts it and we are proud of it. But I know that in some developed countries you can be reported to child services for such. So I was careful not to imply that it's the same everywhere.

<comment><USER6> Child protection services are a deterrent, yes, but not as strong as one would think. Children usually just endure violence because they think it's normal, or they know child protection services will break their family apart. Abusive parents typically are denounced by other adults, like doctors or teachers.

Still, according to page 172 of this report, it seems you're right, because UNICEF puts more effort at developing countries, although their scope covers much more than just domestic violence: [https://www.unicef.org/publications/index_74865.html](https://www.unicef.org/publications/index_74865.html)

</comment></comment></comment></comment></comment><comment><USER7> _A 2018 study published in the American Journal of Physical Anthropology concluded that the Gombe War was most likely a consequence of a power struggle between three high-ranking males, which was exacerbated by an unusual scarcity of fertile females._

Ref: [https://onlinelibrary.wiley.com/doi/abs/10.1002/ajpa.23462](https://onlinelibrary.wiley.com/doi/abs/10.1002/ajpa.23462)

</comment><comment><USER8> I went to a talk by Lawrence Freedman [1] in Oxford where he discussed this war. He has a chapter dedicated to it in his book 'Strategy: A History' [2] (which I highly recommend).

[1] [https://en.wikipedia.org/wiki/Lawrence_Freedman](https://en.wikipedia.org/wiki/Lawrence_Freedman) [2] [https://www.amazon.co.uk/Strategy-History-Sir-Lawrence- Freed...](https://www.amazon.co.uk/Strategy-History-Sir-Lawrence- Freedman/dp/0199325154)

</comment><comment><USER9> Considering that Chimps have reached stone age, it will be interesting to see if Chimps use any weaponns if such a war happens again.

[http://www.bbc.com/earth/story/20150818-chimps-living-in- the...](http://www.bbc.com/earth/story/20150818-chimps-living-in-the-stone- age)

<comment><USER10> They're smashing heavy rocks against nuts... Surely there's a huge difference between carving a weapon and finding a rock large enough to smash open a nut.

<comment><USER11> Well, to be fair, our Stone Age did take 3 million years to complete.

</comment></comment></comment><comment><USER12> This is simultaneously really cool and really sad.

</comment><comment><USER13> There's a documentary or two of this kicking around on Youtube and elsewhere. Much better than this wiki article.

</comment><comment><USER14> I would hardly describe a conflict involving a total of 14 adult male chimps a "war".

<comment><USER15> Then you don't understand chimp culture. Chimps do seriously "go to war" against other tribes. You have to remember that humans killing humans for the sake of "I just don't like you or your friends" is not the norm in the animal kingdom. So yes, it really is a "chimp war", despite their relatively small numbers.

<comment><USER16> I'm pretty sure they're objecting specifically to the "relatively small numbers" part; I probably wouldn't call a conflict involving only 14 _humans_ a "war" either, culture or no culture.

<comment><USER17> Maybe a "feud" a la the Hatfield & McCoy?

<comment><USER18> Anthropologists do sometimes use the terms "feuds", "blood feuds", or "raiding" for this type of conflict in small groups of humans.

</comment></comment></comment></comment></comment><comment><USER19> After reading many, many stories about the absolute horrors of the natural world, I have such a difficult time understanding a belief in a benevolent god. After all, it is trivially easy to imagine a universe with less suffering (but perhaps still enough hardship to drive inquisitive and motivational behaviors), so the presence of so much unnecessary horror in nature leads me to believe either (a) God is a sadist or (b) natural selection in the face of scare resources is what causes this pain.

One of my favorite (or, rather, terror-inducing) examples is the parasitic emerald wasp, which uses its paralyzing sting to turn a cockroach into a "zombie" so it can drag it by its antenna into a burrow, then lay eggs on the roach, and when the larvae hatch they proceed to eat the roach, but in a specific order so that the organs necessary for survival are eaten last. Queen Cersei from Game of Thrones couldn't come up with more nightmare-inducing torture.

<comment><USER20> If the worst form of suffering you had ever encountered was a splinter on your foot, you would make the same claims. "After reading many, many stories about the absolute horrors of splinters, I have such a difficult time understanding a belief in a benevolent god..."

The suffering in the natural world seems terrible to us, but it could be nothing in the face of larger, unknown forms of suffering. We are limited by our imaginations, having no reason to believe we have access to anything approaching deep universal truths of suffering or divinity.

I say this as an atheist. Your argument struck me as a poor one.

<comment><USER21> > We are limited by our imaginations

"we"? You don't speak for me.

You sound to me like you've had a decent life and it's you that can't imagine (consider yourself lucky). Not everyone has your fortune.

Your argument struck me as a poor one too.

</comment></comment></comment><comment><USER22> The question that is unanswered is whether or not the chimpanzees were mimicking human behavior. Or if their violent tendencies are genetic in nature.

<comment><USER23> Bullshit. These chimps have never seen humans killing each other.</comment></comment>


Simple collaboration tool for people, not teams. Help us validate the idea - <AUTHOR>

Most collaboration tools are built for teams and businesses and not for regular people.
We are building a simple and easy to use Collaboration tool that will help you share Files, Links, Photos and Text. You will be able to create boards and invite people by their email ids. You get
Unlimited Storage space, Unlimited boards, and Unlimited invitations
The plan is to have a free version that has all the important features.
Please fill out this small survey : https://docs.google.com/forms/d/1DkP3u0R2tBiFA9U7UeibOYbbB1frAPkhIXSfygVfeOk/viewform
Will really appreciate any feedback!
PS: Survey Link in comment section too. <comment><AUTHOR> Survey Link

[https://docs.google.com/forms/d/1DkP3u0R2tBiFA9U7UeibOYbbB1f...](https://docs.google.com/forms/d/1DkP3u0R2tBiFA9U7UeibOYbbB1frAPkhIXSfygVfeOk/viewform)</comment>


The Psychological Dispositions of Self-Identified Libertarians - <AUTHOR> http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0042366 <comment><USER2> In the same way that Trump seems to have changed the norms of politics, it seems the election has changed the norms of HackerNews.

I wonder what the odds are that my HN RSS feed will stop being 30% political crap that's completely unrelated to tech...

<comment><USER3> Political threads are mostly bad when people use it as an outlet to complain and add nothing relevant to the discussion. This article is relevant since there is likely a disproportionate representation of Libertarians on HN

<comment><USER2> And yet it's still utterly unrelated to _tech_.

If we're gonna start including topics that are slightly tech adjacent, IMO you destroy the key differentiator that makes HN worth frequenting.

<comment><USER4> Plenty of good posts here are unrelated to tech (Pushkin's fiction, J.L. Austin's Saturday morning seminars), so that's not the issue. The differentiator here is "stories that gratify intellectual curiosity".

Please see [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html).

</comment></comment></comment></comment><comment><USER5> Ayn Rand on libertarians:

[http://aynrandlexicon.com/ayn-rand-ideas/ayn-rand-q-on-a- on-...](http://aynrandlexicon.com/ayn-rand-ideas/ayn-rand-q-on-a-on- libertarianism.html)

Summary: _" Libertarians are a monstrous, disgusting bunch of people"_

<comment><USER6> Another quote, showing her true motives:

"I don't think plagiarists are effective. I've read nothing by Libertarians (when I read them, in the early years) that wasn't my ideas badly mishandled"

</comment></comment><comment><AUTHOR> tldr;

(Below I am copy pasting some interesting quotes from the paper)

\- libertarians reject moralities based on ideas of obligation to other people, groups, traditions, and authorities.

\- Libertarians scored relatively high on just one moral concern: liberty.

\- Libertarians will rely upon emotion less – and reason more - than will either liberals or conservatives.

\- libertarians have a strong sense of self and the self's prerogatives, and a correspondingly lower sense of attachment to others. They exhibit a high degree individualism, a low degree collectivism, and generally report feeling less bonding with others, less loving for others, and less feelings of a sense of common identity with others.

<comment><USER7> >\- libertarians have a strong sense of self and the self's prerogatives, and a correspondingly lower sense of attachment to others. They exhibit a high degree individualism, a low degree collectivism, and generally report feeling less bonding with others, less loving for others, and less feelings of a sense of common identity with others.

Politics completely aside, that sounds like a lonely, painful way to go through life. Shouldn't people with these inclinations find out ways to improve their relationships with others? I've never heard a libertarian self- identify as a misanthrope before, so I would think they _want_ relationships with others.</comment></comment>


The Way We Look at Technical Debt Is Wrong - <AUTHOR> http://bigeng.io/post/118399425343/why-the-way-we-look-at-technical-debt-is-wrong <comment><USER2> From years of experience, I detect in the tone of this piece a certain notion that product managers / non-technical people tend to form when working with developers - namely, that developers _don 't_ care about speed-to-market and would rather agonize and winge over perfect architecture and coding standards... What I think you'll find, more often than not, on the business end of this attitude is a developer(s) patiently trying to explain that speed- to-market _is_ , in fact, directly related to the technical debt accrued on the project for all but the most static and inconsequential things. We must think and communicate about technical debt precisely the way we do to keep errant PMs from drifting off into the Ice Cream Sea of Candyland where all of the half-thought-through ideas they demand be implemented immediately by cutting all corners have no impact on the _next_ set of half-thought-through ideas they want implemented.

<comment><USER3> New PMs are like children, they tend to only learn the fire is hot by actually getting burnt.

Instead of digging my heels in on not giving such PMs everything they want, I try to offer alternatives and put the choice on them: they can have this feature today and in 6 months we grind to a halt because we can't fit in anything new, or we slow down just half a beat and do it right the first time. "Up to you, buddy," I say.

It happens with jr. devs, too. They want to use a singleton to solve a problem, or they want to forgo using any sort of referential constraints in their schemas.

Of course, the PMs and jr. devs always choose the shortcuts. I help them both pick up the pieces afterwards, but I never work overtime for it. The point is to make it clear that nobody other than themselves is responsible for their own mistakes. They led us into the mess, they can lead us out.

After that, everyone seems to get along a lot better and everyone seems super keen on having discussions about the "right" way to do things and how to fit things into the current state of the project correctly.

<comment><USER2> || they can have this feature today and in 6 months we grind to a halt

Buy some daisies and chocolate for the PMs you work with... because here's how that would go over with the ones I've had:

PM: "Yes! Cut all corners and get it done today!" ...6 Months go by... PM: "I came up with a new idea for that! Today, please!" DEV: "But remember..." PM:"Today, thanks!"

<comment><USER3> You do a job. There is a reason you are there, and it's not to write code. It's to fulfill requests. Feel free to provide advice on how best to fulfill those requests, provide feedback, ask for clarification, etc. But at the end of the day, all you do is what you are told. It's not to anticipate what they will want in 6 months, because you'll be wrong just as often as right and you'll be in the same scenario. Just do your job.

So when you're told to cut corners today, then in 6 months you can't make magic happen to grant their every whim, you have to let it blow up. They want to be the leader. They are responsible for the failings of the team.

You have to play chicken with them. Because every time you capitulate, all they know is "I got what I wanted". They don't care how much you complained or how many hours off the clock you worked. And honestly, if you tell them it can't be done overnight, and then you do it overnight, you're a liar and they won't trust your judgement ever again. When you say, "can't do it", you _have_ to _not_ do it. Don't make magic happen.

Or just don't work at such places. I have thankfully been out of that bullshit for three years running now.

<comment><USER4> That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment.

As you say, _don 't make magic happen_. It doesn't matter how cool it would be if, or how you think you'll show them your ideas are better; when you say "it cannot be done" don't go and try and do it. Don't let the manager bully you and don't let them try and get another developer to tackle the impossible.

I've had that happen to me where I said it will take X amount of time to do it so let's not do it till next sprint. Then the manager went around my back when I was gone for a day and gave the task to another dev. The dev, who caused the mess, of course was able to fix it within an hour. Why did I say X amount of time? To cleanup and make sure the bug stays fixed.

When you work with other developers, actually _work_ together. Stand up for them, don't make bad comments about them, and always stick together when you're asked to do the impossible.

<comment><USER5> If I understand your story correctly, that other dev accomplished the task in some characteristically short amount of time, plus an hour for fixing a bug.

While you didn't specify what your "X" was, it sounds like the manager (and the company) got a better outcome by going around you and it was far from being "asked to do the impossible".

<comment><USER6> I believe his point was that there's often a difference between finishing the task and actually fixing the issue.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> The author seemingly misses an important way in which this can be looked at as "real".

Some subsystems don't change much because they already do what is needed and aren't broken. Sure, the code could be improved, but it's not important enough to do (or at least, to do now).

Other subsystems don't change much because they are scary to change. If the system is brittle and poorly designed, engineers may have very good reason to be hesitant about changing it, and instead it is worked around.

So this latter case behaves very much like "technical debt" . This system costs you engineering time every time you even think about touching it. It's hard to reason about, it's hard to change, and over time these problems get worse if you introduce workarounds in other parts of the system, because now they are worse and harder to work with.

This is a very real cost.

<comment><USER8> This is a good point, but I think it's very much in line with what the OP is saying. Technical debt _hampers your ability to change_. Anything you're scared of changing clearly fits that description.

Those workarounds that get created instead of changing the scary thing put me in mind of the "scar tissue" metaphor that SapphireSun proposed elsewhere in this thread.

<comment><USER7> I'm not disagreeing with the main thrust of the OP's argument, but with the statement that "Technical Debt isn't real".

I think that it often is best thought of as "real debt" in that it costs you time and attention, and (at least some of the time) that cost compounds over time. In other words, some of your engineering spend is just going to service this debt, not produce anything useful. That's a very real opportunity cost.

</comment></comment></comment><comment><USER9> I'm unconvinced that accepting large amounts of technical debt allows startups to react faster.

I've definitely seen startups that have _almost_ found a good idea, but can't tweak it, scale it, or make it stable, because they're overwhelmed by technical debt and even simple changes have become engineering death marches.

Letting your back-end code turn into a complicated, disgusting mess means that adding critical features may become a multi-week nightmare. Which is then followed by a series of additional multi-week nightmares for each successive feature.

Now, this isn't to say that obsessive code-polishing is a good idea, either. But startups require rapid iteration, and you can't iterate especially rapidly when your code is complicated, badly organized, and poorly tested.

<comment><USER10> One of the most valuable startup skills is to know which kind of debt has a low interest rate and which kind of technical debt has a high interest rate. Certain things - lack of tests, poor build system, poor deploy system, very poorly structured code - have a very high interest rate. Every time you create bugs, you waste time tracking it down and fixing it. Every time you check something in that breaks the dev environment for the rest of the team, you create bugs. On the other hand, messy code that is isolated to one system, or an architecture that has a bit of copy and paste, are usually not too big of a deal. Going on some deep dive to create some "generalized framework solution" is almost always an error.

<comment><USER11> Some people talk about Reversible Decisions, and I think what you're saying plays into that sentiment.

Unfortunately some people don't realize that in many situations not making a decision is itself a decision, and so they don't always notice it when it happens. That can be anything from the ones you mentioned, like testing and tools, to authentication, auditing, localization, robust error handling, resource/memory leaks, or monolithic designs that prevent scaling.

</comment></comment></comment><comment><USER12> I don't believe that, even in the short run, taking shortcuts actually saves you time. It's much like working 12 hour days - you feel more productive, but you're not actually getting any more done on a larger scale. There's an obsession with 'hurry up and get it done' that contributes little on a larger scale.

I also don't believe it's possible to pick the 'important' areas of code _a priori_ and make only those areas free of technical debt. Doing good work is an attitude, a mind set, and something to practice - if you practice making poor quality code, it's going to affect you across your work, not just in the places that you do it.

I think that, by being professionals and putting aside the 'hack it out' mentality, we can improve not just the code that we're working on, but our mindset towards it. How many codebases have 'that scary part' that adds background anxiety to the people that work on it? Is that something you want to invite into your life on an ongoing basis?

Especially for things as important as integrations into external APIs - sure, they may not change much, but in my experience you _really_ want to make sure they're done right when they're _how you deliver your product to customers_. Given how error-and-failure-prone many external APIs are, I expect a lot of work there just to robustly handle the other end of your integration being flaky.

I think that quality is something you can't 'bolt on' later. It has to be built in, top to bottom, throughout your organization, code base, and personal skills.

<comment><USER13> But often the choice is: do I implement this in an hour, _or_ do I spend a week making a nice well-though-out framework for this, complete with test- suite (which may take multiple iterations to reach perfection).

And you may pick the latter, but what if management wants to make a quick prototype and turn that into a product later? At that point you'll still be having the "technical debt" talk with your manager.

<comment><USER12> I think that's a straw man argument - the choice isn't between an hour and a week, it's a choice between an hour and two or three hours. I don't think that making a framework for every change is a good idea, but I do think that, if you've only got an hour to work on something, you'd better make some quality tests for it, because under time pressure you're _even more likely_ to make the sorts of errors that tests catch.

That said, I'm not implying that you should slow down, just _do the best possible work at all times_. Don't do a crappy job just because you're time- limited - we all only have 24 hours a day, and there's always more work than can reasonably fit in. The moment you start going "I am going to lower my standards right now", you've started a trend.

I think it's interesting that people are always saying "hire the best possible people you can", and then saying "but don't ask them to do the best possible work they can do".

<comment><USER13> But a good programmer always sees a number of solutions to a particular problem. Let's say he sees 10 solutions. Solution 1 costs an hour to implement, but gives crappy code and he knows it. Solution 9 gives good quality code, but takes a week to implement, and he then has to sell this to his boss.

And then there's solution number 10, which requires the programmer to invent a new programming language, and requires at least a couple of months to develop. "You hired the best possible person for this job, so let me do the best possible job".

I just bet most people here wished they could always deliver the best possible code.

<comment><USER14> >But a good programmer always sees a number of solutions to a particular problem. Let's say he sees 10 solutions. Solution 1 costs an hour to implement, but gives crappy code and he knows it. Solution 9 gives good quality code, but takes a week to implement, and he then has to sell this to his boss.

A good programmer will try and improve code the code _incrementally_ , and won't bother trying to sell anything.

</comment></comment></comment></comment></comment><comment><USER15> "Financial debt, however, accrues interest and hurts more regardless of what it is incurred for."

I'd disagree, I think all technical debt accrues interest (similar to financial debt), but the interest rate is different. As the example about a usps api demonstrated, that has a near 0% interest rate. Of course if you were ever to need to update it (maybe usps updated its api) you'd get hit. A bad domain model has a high interest rate. All the ideas are the same though, i'm just being persnickety :D

<comment><USER16> A problem with comparing the metaphorical debt of technical debt to the financial one is that interest rates can be negative.

In addition, the term "debt" also applies to moral aspects, and not just financial ones. A builder may come back and improve something not because it's good for the employer or has financial benefits, but because of a belief that quality is good for the soul of the builder. That is also an aspect of technical debt.

Regarding the original article, it says tech companies are "successful because they got a product to market fast and at the right time". The "fast" is incorrect. Companies are successful if they are at the right time. If a company (like GO Corporation with pen-based computing) is fast but too early, they they are not successful. If a company (like Microsoft with Excel) is slow but eventually gets there, then they are successful.

"Fast" is therefore irrelevant in the face of "the right time." It can be that the right time is "as soon as possible", but that's not intrinsic to success.

<comment><USER17> >If a company (like Microsoft with Excel) is slow but eventually gets there, then they are successful.

Excel was successful because Lotus decided 123 had so much technical debt it would be a good idea to "upgrade" the old assembler code to C. This took at least a year longer than planned, and introduced a lot of bugs and incompatibilities.

Meanwhile Windows had arrived, and the planned Windows rewrite of 123 never happened as scheduled.

So it wasn't so much that technical debt killed 123. But _poor management_ of technical debt certainly did.

Effectively the C rewrite was a complete waste of time, and Lotus should have aimed for a Windows release as soon as they could.

It's nice to be able to say this with hindsight, but it was doubtless much less obvious at the time, when Windows was barely considered a mediocre visual DOS shell, and certainly not a serious OS.

Bottom line - you have to be smart, prescient, and a little lucky to manage technical debt. It's not just about getting the code right - it's making decisions with educated guesses about where you may be a year or two from now.

And _that 's_ hard.

</comment></comment></comment><comment><USER18> I don't think the metric 'any code that decreases agility as the project matures' is quite the same thing. I think most code lowers agility, as it is increasing complexity and the number of interactions and entanglements across your codebase. Adding features decreases agility. These are not 'technical debt'.

I always enjoy Ward Cunningham's discussion of this: [http://c2.com/cgi/wiki?WardExplainsDebtMetaphor](http://c2.com/cgi/wiki?WardExplainsDebtMetaphor) (Ward first used the metaphor)

Specifically, he is NOT talking about 'dirty code' or just badly written code, that's taking shortcuts and I believe it is never a good idea in software. We're talking about building good code but doing so before we fully understand the problem, often with the aim of learning more about the problem, especially from user feedback.

What I take Ward's discussion to mean is that "technical debt" is accrued when writing code for a problem you do not YET completely understand (e.g. almost all 'first pass' code). The debt occurs when your code's existing understanding is static (because it is in source control), and your teams understanding grows. The difference is your debt. You can continue building on the code's not-quite-right understanding for the moment which is carrying the debt forward and paying the costs of fighting a not-quite-right model, but at some point it becomes worth while to re-factor based on what your team has learned about your problem, and thus pay off the debt.

<comment><USER19> I don't necessarily agree that adding features decreases agility. Sometimes it can massively increase agility - especially if your product is built in a way that a new feature can immediately gel with other features.

But apart form that, absolutely. Technical debt in the article isn't the technical debt that was originally coined.

I still think the common meaning of technical debt is just as important though. Code that can't be taken forward, for whatever reason, costs its owner.

</comment></comment><comment><USER20> In the past 15 years I've been in a situation twice where shipping something NOW was more important than taking the time to do the needed cleanup. Simply because the competition was breathing down our neck, and taking a break to refactor stuff would just give them an opportunity to bury us. And who's going to care about your code quality then?

And it wasn't just crappy web apps or throwaway MVP stuff. The first one was in medical systems, where the suits figured we had a 6 month lead on our closest competitor, the other was in consumer electronics (navigation devices), in the time that competition was still stiff in that sector.

In both cases it was decided that releasing something was more important, knowing full well that we had to pay the cost later. Of course not everyone agreed with it, since no one likes having to work with legacy crap, and everyone and their mother always wants to refactor all the things, but guess what: code quality is not the goal of your company, making money is.

<comment><USER21> > rushed software

> medical systems

Oh no.

<comment><USER22> It's more common than you might think.

Most software, especially middleware and EHRs, are the worst sort of enterprise garbage.

</comment></comment></comment><comment><USER23> The article applies mostly to short-lived webcrap and appcrap, where time to market matters. There's software where reliability matters more than features - databases, for example. Source code repositories. Banking systems. Soon, automatic driving. (The coming "Internet of Crappy Things" is a real worry.)

<comment><USER12> I think that quality matters even in 'short lived webcrap and appcrap' \- you only get one chance to convince your customers to trust you, and if your application even so much as _behaves subtly wrong_ they're gone. I think that's the class of error that 'hack it out' most causes - it's not an application error, it's an error of logic or off-by-one or floating-point- math-where-it-should-be-exact.

</comment></comment><comment><USER24> I hate to put it this snarkily and I fully expect karmic blowback, but I'll just go out on a limb and say that what we need more of is not hastily shipped crapware that barely functions and if successful keeps a legion of smart engineers busy, cursing, hacking, grinding teeth and tittering.

No, what _you_ need is more hastily shipped crapware to capture markets from your competitors so you can make more money and disappear. Hastily shipped crapware has enabled lots of new and interesting things. It also keeps 10x as many engineers busy serving it as would moderately better thought out, slightly later shipped software. Babysitting crapware isn't bad money for an engineer, but it's cosmically questionable as to whether it really advances us more than its opportunity cost. And hastily shipped crapware at scale is a real giant energy problem. Take a look at the size of a Facebook datacenter and tell me again how a metric fuckton of PHP is a good thing for the environment.

</comment><comment><USER25> IMO This is all you need to know about "technical debt"

1/ Poor code =/= technical debt. Far too often, poor code masquerades as "technical debt"

2/ Good engineers do the right thing which is always a judgment call based on circumstance & culture.

3/ Take guidance from your best engineers, and find a way for the business to adapt. Much easier to change the sales deck or pricing today, much harder to overcome bad technical decisions. No one ever said "I never knew that sales deck or pricing would last this long" but many say this about software. Be super careful & deliberate.

4/ Build things that are simple (not easy), and respond to demand. Focus on movability & robustness, not "perfect" design.

<comment><USER3> Your #1 is spot on. Every "grind-to-a-halt" scenario I've been in has been because we expected X number of users or Y amount of data and once we released it turned out to be 100 times those numbers. The system you build for 10 internal users is going to look a lot different than the system you build for 1,000 users on the internet, and that's going to be completely different than what you build for 1,000,000 users. That doesn't make the small system poorly designed, it just makes it inappropriate.

<comment><USER25> Interesting. Not my experience. Every grid to halt scenario I see or hear of is just bad software decisions made under haste without deliberation, or foresight beyond initial launch (no attention paid to supporting it, let alone scaling)

Ergo, in your scenario even with 10 users, the application basically died under its own weight under nominal use.

</comment></comment></comment><comment><USER26> So... be agile agile agile... but, not really.

Don't waste time trying out the latest-and-greatest cutting-edge development techniques. Except SPAs (Single Page Applications) because those (somehow) take less time to implement and are 'easier' to iterate than a traditional UI.

Don't waste time perfecting the data models. Unless you're talking about data structures (ie they're _totally_ not a type of data model) because your data structures should be perfect from the start so as to avoid the technical debt of modifying them later.

Don't waste time enforcing the SRP (Single Responsibility Principle). Unless you're talking about 'siloing areas of concern into microservices' because splitting responsibilities (and designing custom APIs to drive them) isn't just another approach to enforcing SRPs. Designing APIs that connect your app to it's dependencies in a manner that won't change (and break things) later is easy right?

So, code, code, code fast. Don't waste time early on developing a sane architecture, except when you want to spent time developing a sane architecture early on to iterate quickly later.

Forgive the sarcasm, this isn't a troll. I'm just pointing out the blatant contradictions.

The only valuable advice I can grok from this article is. Disregard TDD, build a MVP, push it into alpha/beta ASAP, fix bugs later.

</comment><comment><USER2> From years of experience, I detect in the tone of this piece a certain notion that product managers / non-technical people tend to form when working with developers - namely, that developers _don 't_ care about speed-to-market and would rather agonize and winge over perfect architecture and coding standards... What I think you'll find, more often than not, on the business end of this attitude is a developer(s) patiently trying to explain that speed- to-market _is_ , in fact, directly related to the technical debt accrued on the project for all but the most static and inconsequential things. We must think and communicate about technical debt the way we do to keep errant PMs from drifting off into the Ice Cream Sea of Candyland where all of there half- thought-through ideas they demand be implemented immediately by cutting all corners have no impact on the _next_ set of half-thought-through ideas they want implemented.

</comment><comment><USER27> There are some things I agree with in this, however I think the context in which it is presented is flawed. This is particular: "Technical Debt is a Positive and Necessary Step in software engineering" is just incorrect. If technical debt was positive and necessary we would call it Technical Credit.

IMO a better context for this would be: real software engineering requires compromises. There are a number of competing factors that need to be juggled in order to be successful: time, money, complexity, quality, etc. The point should be that you need to balance these factors, not focus on one above all else.

</comment><comment><USER28> Ehh... what's this "we" stuff? I think the way a lot of people look at technical debt is correct, not taken from the perspective the author seems to have where debt is always bad, but rather taken from the perspective that the term "debt" is meant to convey.

Financial debt (contrary to the implied sense I get from reading this article) isn't always a negative -- business loans and even VC capital are forms of debt without which many companies wouldn't be able to exist, mortgage debt is debt without which very few people would be able to buy a home. These are useful tools. Likewise, accruing technical debt is often just part of the process of writing software, especially when "bootstrapping" new projects. In moderation, it isn't bad at all, but like financial debt, you do have to manage it, see it as a risk factor and not let it spiral out of control or else it will become very destructive.

</comment><comment><USER29> Either this was poorly written or the author just doesn't get it. Developers shouldn't do TDD or 100% code coverage because they want to build a perfect system; developers should do TDD because they understand that they can never build a perfect system and the T in TDD protects them from complete failure. This means you never attempt to build a perfect system; you only attempt to do just enough. What is just enough? It is the amount of functionality to make the tests in TDD pass... never the amount of functionality to make others 'fall down on their knees and claim "we're not worthy!"' Thought I'd also add that technical debt is unavoidable, but we realize it is not OK to have technical debt (the article concludes that technical debt is OK) and that is why we back it up with tests. These tests are like collateral for a loan (technical debt).

</comment><comment><USER30> A simpler way to look at technical debt is to ignore all kinds of dubious notions of "quality" and "correctness" and focus on lines of code.

The more lines of code you have, the more stuff you have to maintain and understand.

Of course this is pretty stupid, but it's stupid in a way that sometimes leads to insight.

If your application consists of 1000 lines of code, you can rewrite it in an afternoon.

Also, cleverness can create its own kind of debt. Even as you believe you're working on reducing debt by creating some clever and sophisticated abstraction, you are actually just making it worse. I think this happens all the time.

That's why my basic, fundamental approach to software development is "throw it away and replace it with a simple shell script."

</comment><comment><USER31> Can someone please tell me the audience for this essay? Is there a company out there where they're so careful to follow good practices and control technical debt that they're erring on the side of too much quality? And are they hiring?

<comment><USER32> > Can someone please tell me the audience for this essay?

There's a clue in this quote:

> The most successful cities in the world, such as New York, London, > Vancouver, Sydney, etc

A big city in each of the 4 largest native English-speaking countries of the world, in descending order of population.

</comment></comment><comment><USER33> This has been my experience in the startup world.

My startup went from a few scribbled notes on paper to a full app in the app store in three months, including 50 lessons, 6 mini games, and a challenge/achievement system.

Naturally, I had to cut a LOT of corners to do that, and accrued a ton of technical debt, but I was able to keep the high level architecture relatively supple, and as a result tackle the various messes individually rather than as a whole later.

It paid off. Or architecture has since changed twice over so none of the old code remains, but we're strong on investment, have lots of people, and are poised to take over our target market. And we got app of the year last year.

<comment><USER34> I'm a firm believer in the adage "Build the first version to throw away; you will anyway."

[https://en.wikipedia.org/wiki/The_Mythical_Man- Month#The_pil...](https://en.wikipedia.org/wiki/The_Mythical_Man- Month#The_pilot_system)

I feel like that's it's own idea and should not be confused with technical debt. The article seems to make this conflation as well.

</comment></comment><comment><USER35> Minimizing technical debt before launch or major milestones is huge because, on occasion, that debt can compromise all future estimates/dates/milestones if it is not addressed.

I think developers, including myself, like to get things right before launch because fixing it after launch is harder, if not impossible once other emergency/technical debt comes in and starts layering on top of that debt.

If this goes on for 1-2 cycles, before long your app, backend and internals look like a shanty town that no developer wants to enter.

Sometimes I wish code was visual like buildings, you could more easily see quality that way. Mostly though you have to believe in your developers/engineers that what they are building is a mansion/building you want not a shanty town dwelling that is held up on duct tape and silly putty, yet the technical pressure/debt put on is largely coming from someone who can't see the visual representation of the system.

Developers can only be MacGyver for so many release cycles before instability strikes the system down if management is not careful.

There will always be some amount of technical debt but developers do love to get things done and out the door as fast as possible. We like to do so with a minimum amount of technical debt as it is a constant battle against time/market/cost with quality.

</comment><comment><USER36> "This is why single-page applications have grown in such favor over the past few years; they allow quick agility at the UI layer without the need for API changes."

I haven't seen anyone else comment on this sentence, but I'm baffled by it. The first and second parts don't seem in any way connected, nor at all in keeping with my experience of building SPAs - the UI layer is often intricately complicated and every bit as hard to iterate on as an API!

<comment><USER37> Not only that but I've found SPAs to be more complex than their traditional counterparts, mainly due factors like: the extra layers & complexity involved, churn rate of & lack of maturity in JavaScript frameworks, lack of integration with backend of choice. Of course there are advantages to SPAs and this generally is my choice of architecture, however I definitely wouldn't say that SPAs are more agile at all.

<comment><USER38> yes, usually you end up a lot of MVC on both the front and back end.

</comment></comment></comment><comment><USER39> Firstly, the definition of technical debt as anything that reduces your ability to change in the future rings true, and is definitely a good way of thinking about it.

And I accept that there are times when you can move faster by accepting technical debt.

However, I'm always uncomfortable when this view is preached, because I think that while all these things are true, they are rare. The most common case is that when corners are cut, or 'tactical' solutions are adopted, you begin paying for them within a week, often before you've even finished implementing them. Another common case is that doing something in a way that allows future change is almost no extra effort compared to taking on the technical debt, but the vision or mental effort (or political will....) isn't there to even try to see things in a new way.

So sure, sometimes we should embrace technical debt wholeheartedly, but most people are already too far in that direction already. I'd rather read articles about people who spent a little extra time thinking in these situations and came up with a solution that was quicker to implement than the original plan, with less, simpler code and fewer bugs. I think such things happen just as often as technical debt producing good outcomes.

</comment><comment><USER40> Half of my shortcuts are wins, and half are ridiculous sinkholes of time.

The trouble is, I don't know which half is which until it's too late.

</comment><comment><USER4> >Technical debt is ok, and often a solid product strategy. The importance is getting to market.

Apparently they're using Rails or PHP at Bigcommerce. If you're trying to get to market as fast as possible then Rails makes sense but what goes with Rails is TDD. You really shouldn't have too much technical debt when you're using Rails or Ruby.

On the other hand, if they're using PHP then I'd bet a lot of money that they have a lot of technical debt because they hired poorly skilled developers who were able to push through some code that _looks_ like the feature requested.

At some point, you will be crushed under the weight of your own technical debt. The race is whether your startup will die before that point. The author sounds like he's trying to get acceptance that there will _always_ be technical debt. How about letting your engineers working on refactoring and making things nicer?

Facebook could have been crushed by their technical debt but instead they let their engineers loose on the code base. That's how they've come up with Hack lang which is type-annotated PHP, and that's how they've come up with flow, the javascript type checker. This is why they made it a mission to allow developers to be able to fix and deploy some code within 1 week of starting a job. All of that forces them to fight against technical debt and to keep themselves in the game.

That's the real issue here; sure it sucks creating technical debt in an effort to get to market first, but it sucks even worse when as an engineer you aren't allow to tackle the debt at any point or are only allowed to tackle it very rarely. Efficiency is what will keep the dollars rolling in.

A recent example involving Google is Chrome. People are actively switching back to Firefox or another browser. There's bloat in Chrome! How's that possible?! My bet is a product manager who isn't allowing the engineers to fight the technical debt in the code.

</comment><comment><USER41>
        Systems take too long to get to market, which causes
        marketing efforts to stall or become irrelevant, and
        competitors beat out the startup to an offering.

I disagree. Well, maybe I agree in part, but I feel like this misses the forest for the trees. Getting to market fast helps you get in front of users (and prospective users) faster, which—assuming you're listening to them and iterating—helps you achieve product/market fit before you run out of capital or a competitor does the same.

Wikipedia has a bunch of great links to more on the topic if you're unfamiliar with it: [http://en.wikipedia.org/wiki/Product/market_fit](http://en.wikipedia.org/wiki/Product/market_fit)

</comment><comment><USER42> Of course code quality is important, but some good points here, and I agree that 'technical debt' is quite different from financial debt. For example (beyond the points made in the post) maybe you have 'technical debt' on a bunch of code that becomes irrelevant and gets deleted (or reimplemented completely differently, or whatever) so that you never actually have to pay that 'debt'. I quite often find myself doing a kind of 'just in time refactoring' at the point where it becomes clear that code quality issues actually make it difficult to think about what the code is doing, or implement necessary changes.

</comment><comment><USER43> Maybe instead of calling it technical debt, we should call it scar tissue if you want to focus on the agility aspect.

</comment><comment><USER44> I'm going to add a comment about non-software technical debt. Think about technical debt in residential home construction. When a home is built, it requires a footing, a foundation, framing, sheathing, electrical, plumbing, insulation, roofing, etc. However, homes are typically designed "statically" in that they don't frequently change shape.

As a result of that, when it comes time to renovate the house, the workers doing the renovation frequently find that nothing about the construction of the original house was designed to make it easy to extend or add to the house. even things as simple as adding light fixtures can require running wires all through the house back to the electrical box, cutting holes in walls, patching walls, moving insulation, etc. When you go to add rooms, you find that the way the foundation was poured means you'll need to remove existing foundation drainage systems to add new footings, add new foundation, add new drainage etc. Then, tear everything apart to add more electrical and plumbing. and finally, tear apart a big portion of the roof to merge the shingling on the roof.

Houses _are_ static, and thats why we tolerate building things this way. We can't predict how they might change in the future, or what the needs might be. If you could/did, you could mitigate almost all of those challenges I mentioned earlier.

In software, we do know that it will change, and we frequently can predict where and how those things might attach. Because we can predict those things means that we should design our software to be ready for those expansions as well as possible to minimize major structural changes to the whole applications in the future.

</comment><comment><USER45> The way I look at it, is that "doing things right" is a risk. It will always equal faster "speed-to-market" in the long term. I think we're just afraid to admit that "doing things right" very often ends up not working out. At all. If only it were so simple, that we could just take a little bit more time and have that perfect architecture and test coverage. In reality we often end up making something that's not "right" at all. Or worse - nothing.

I don't see taking on "technical debt" as being faster. It's just less risky. You're more likely to have something that does something after that month of work. Hence the common perception that it's faster. In an organization where there's mistrust (rational or not) it's easier (or even better) to take the safe road of "technical debt".

</comment><comment><USER46> By the by, there's a recent software engineering radio podcast on technical debt:

[http://www.se-radio.net/2015/04/episode-224-sven-johann- and-...](http://www.se-radio.net/2015/04/episode-224-sven-johann-and-eberhard- wolff-on-technical-debt/)

</comment><comment><USER47> In a perfect world I agree. I feel however, that I'd be more successful with slow more correct development over fast and loose development, because the latter requires immense determination and follow-through, at all layers of the business.

The most important thing is always to make money. The most important money is the money you make this week, not the money you might make in a year, and you have weeks of potential money queued. It's equation is never right to spend a few weeks not making money so down the line you can potentially make other money at a slightly fast rate. It's definitely never the right time to do that over and over again to get the many small improvements that will make you much faster in the future.

</comment><comment><USER48> I'm so glad Bigcommerce is finally taking technical debt seriously, 'cos that place is _full_ to the damn brim with it! (Some of it mine...)

That said, the only reason their business is where it is today is because of shortcuts taken in the name of speed-to-market. In their case, the end really did justify the means - eCommerce is ultimately a land-grab for market share, and BC dove in hard, spent _millions_ on marketing and customer support, and left Engineering to fend for itself. As an engineer, it sucked, but in retrospect and looking at their success to date, I'm willing to concede it was the right choice at the right time.

</comment><comment><USER49> This btw is precisely what separates the good engineer from the great engineer:

A good engineer can produce a good product under moderate time pressure but will accrue technical debt in critical spots if more time pressure is applied.

The great engineer anticipates the change and will not strive for perfection in parts that are going to be rewritten in the future anyways but instead just make it do the job, while at the same time keeping things simple and flexible. That's how they deal much better with deadlines and time pressure.

</comment><comment><USER50> I see a lot of wisdom in this article and I find myself nodding, but I'm dubious whether it's effectively communicated from the article per se or its just my experience dovetailing with the author's. The problem is that "technical debt" is an analogy, and like all analogies, it breaks down. It's never a choice between writing perfect code or hacking together the fastest ugliest thing that could possibly work, rather all long-term software development is a continuous series of tradeoffs heavily dependent on an unknowable future.

Consider the center-point of this article:

> _I view technical debt as any code that decreases agility as the project > matures._

Well, any given piece of code can have positive or negative value based on what change you need to make in the future. You can have a perfectly factored, elegant piece of code which becomes useless if the job to be done changes, at which point you are better with _no_ code than the previously ideal code. On the other hand, you can have a module which is ugly as sin, unreadable, and horrible in every way, but it does a job that never needs changing, and it's isolated enough that no one ever even has to look at it or consider it.

So the very judgement of the scope and severity of technical debt depends non- trivially on the future. Individually design decisions can be critiqued, and the likelihood of certain types of changes can be weighed out, and certainly the best engineering and product teams are very very good at this, but the fact is that the whole endeavor is terribly fraught and difficult to concretize.

All that said, I think the author is absolutely right that engineers often have a proclivity to polish some bit of code or architecture when their time would be better spent elsewhere, but it's just a tiny microcosm of the problem facing all startups: you need to build a money-making machine, and you have infinitely many dials to turn, with only a handful of (hopefully) smart people on a very limited runway. How do you make decisions day-to-day about where your greatest marginal utility lies? I don't think there are any rules of thumb that are globally applicable. If you are lost, a blog article is not going to help you. The only hope is to gather feedback as widely and quickly as possible and be brutally honest with yourself.

</comment><comment><USER51> I'm starting to believe that debt is the wrong metaphor. Imagine you have 1k in debt and 2k in the bank. You're free to pay down that debt, so you do. If you later realize that you actually need that 1k used for the debt, you can simply take out a new loan and effectively undo that step. This is precisely where the tech-debt analogy breaks. When you invest a month into fixing tech debt, you can't get that month back. That decision is final.

</comment><comment><USER52> Making decisions about technical debt is hard. Anybody who tells you otherwise is someone you want to stay away from in a work environment. Every single one of the decisions you make is context dependent, sometimes massively so. You need to know where you are and where you need to get to at every step. Only then can you make good decisions. For what it's worth, here is my list for the places where most people get it wrong.

1) People lie about what is required. Anyone who has been in the industry for more than a token amount of time has experienced the PM who says that they need X+100 when they really need X because "programmers are lazy". Similarly everyone has worked on a team where one or more of the programmers are more interested in building their beloved architecture than solving the problem at hand.

2)People don't listen to the needs of others. Very often they assume problem #1 exists ("They don't actually need that") and blindly forge ahead without paying attention. They play whatever political game that is required to force the other side to follow their approach.

3) People make mistakes. Often this is due to a lack of experience, but sometimes it's just because the problem is hard. Some people make mistakes more often than others. Good management will recognize those that are making good choices, but sometimes you have to let people crash a few projects before you realize that they don't know what they are doing.

4) Choices are made at the wrong level. With all of the other points I've made, it is exceptionally tempting to move all the decision making to someone who acts truthfully, listens well and has a good track record. However, the information required to make a good decision can be at many levels. Sometimes you _need_ 100% test coverage of something and only the programmer will know when this is going to happen. Sometimes you _need_ to deliver tomorrow even if it doesn't work at all. Only the PM will know this.

In order to build a team that executes at the highest possible level, you need to have people who work well together, trust each other and are competent. If you do not have this, then success will likely be a matter of chance. No amount of heroics from a single person can reliably fix the issue -- and often such heroics just make matters worse because they result in the behaviour listed above.

</comment><comment><USER53> Sure, strategically taking on technical debt is sometimes beneficial to the company – just like sometimes taking on personal debt can be beneficial, too.

I think that discussions around technical debt really lack any mention of technical _credit_, the opposite of debt. Just like how you can take on debt in your codebase, you can save up credit, too. In an ideal world, you would always have savings so that you don't have to take on debt.

</comment><comment><USER54> I like the application segmentation strategy (when you can get away with it); it reminds me of the unix philosophy but over a message bus instead of pipes.

Running things over a message bus is slightly more work than one large application, but the upshot is that it lets you experiment with new technologies and ways of doing things without betting the entire product/company on it.

</comment><comment><USER55> Unless you have infinite amount of time, you shouldn't refactor code you didn't need to touch in the first place.

When you have a large enough codebase, you will always find bad code if you look long enough, it's pointless to waste time on that. You should only refactor code that you needed to touch in the first place.

</comment><comment><USER56> Incurring technical debt early on is fine. A large portion of the code for new ideas or new venture are thrown away anyway due to misaligned market or product fit.

However, management need to understand technical debt and their impact on timely product delivery in later stage of development.

</comment><comment><USER57> technical debt is actually worst than financial debt. imagine an interest rate of x%. now imagine that one day the bank comes in and says: now your interest rate is going to be 20x. you don't get a say in it and you cannot refinance.

also another mistake I've seen made over and over again is to say stupidity==technical debt. If you're doing stupid things just to 'get things done' you're doomed in the long run. If you've thought about it and made the decision to cut a corner you should know why you've done it.

</comment><comment><USER58> There is a related idea: refactor code that you need to change, don't refactor code if there is no other change you want to make.

</comment><comment><USER59> I agree with the author more or less at least with respect to compromises between software quality and speed of execution. Code does not have to be perfect, especially when it doesn't affect the end user.

On the other hand this is what I miss most about school, or perhaps just doing things out of my own interest.

There was a time when I could appreciate the beauty of code and all I could worry about whether my software was elegant. Then I joined industry and everything changed.

</comment><comment><USER60> This is a terrible article. The awfulness starts at the title, and continues throughout.

What's wrong with the title: he asserts that "we" all defined technical debt incorrectly, when (in my experience) there's no meaningful agreement on that term. It's one of those terms that, if it's used, requires follow-up to be sure that both parties are talking about the same thing. The author even acknowledges this lack of agreement, but he asserts that we're all using it wrong.

The author then proposes a definition: "any code that decreases agility as the project matures".

Sorry, but there's no polite way to say this: that is, quite possibly, the most useless definition of technical debt I've ever heard. Every line of code decreases agility in one direction or another, every step forward is a step past some other opportunity. Thus, a definition that conflates necessary progress with actual problems is worse than useless. It's harmful. And frankly, I have trouble imagining an intelligent person who would use it. At this point I'm attacking the author a bit, but at this point the author has attacked the entire world a bit, so it seems fair.

The author has made clear that he thinks he's smart, that we're dumb, and he's figured out things we can't understand. So gross.

Captain know-it-all then proclaims, in bold font no less, that "The Most Important Thing is Getting the Thing to the User". No. Fucking. Shit. We fucking know that. We get that. Please don't do this shit where you conflate the whole damned world with the one guy in your office who you're passive- aggressively railing against with this awful awful screed.

Then this just gets into total dishit territory. We're supposed to not worry about getting everything right, but god forbid we need some migrations along the way, no... those aren't acceptable to this bloviation blowhard, we must get them all right on version one.

I now have a better understanding why BigCommerce is about the fifth company I think of when I think of places to host a shop. They're a fifth place company that hires fifth place management.

And Shaun, if I'm correct that you wrote this because you're tired of hearing your team talk about technical debt, then you are truly a horrible manager and you should just fucking quit. I'm not a person who typically advocates quitting, but this seems like nothing more than a passive-aggressive attack on one or more of your engineers who mentioned technical debt or code quality more often than you'd prefer.

And if you really just thought this was brilliant insight: you're an idiot. You used a dumb definition of tech debt to justify an argument that showed you don't understand the original metaphor. You are an impressively stupid man.

</comment><comment><USER61> Couldn't agree more, in fact I have an unpublished draft on Medium that makes similar points. Happy to share if you're interested.

<comment><USER62> oh please, please share it.

</comment></comment><comment><USER63> >For instance, if you're using a relational database, and your models are improperly structured, this will cause you significant pain later on. If you build a system using NoSQL that later needs to become highly relational, you will incur massive frustration in the future.

I don't think this is what Linus was talking about...</comment>


Analyzing latent embedding capacity in Tacotron, Google's seq2seq TTS model - <AUTHOR> Research paper: https://arxiv.org/abs/1906.03402
Audio examples: https://google.github.io/tacotron/publications/capacitron/
Capacitron is the Tacotron team's most recent contribution to the world of expressive end-to-end speech synthesis (e.g., transfer and control of prosody and speaking style). Our previous Style Tokens and prosody transfer work implicitly controls reference embedding capacity by modifying the encoder architecture, thereby targeting a trade-off between text-specific transfer fidelity and text-agnostic style generality. Capacitron treats embedding capacity as a first class citizen by targeting a specific value for the representational mutual information via a variational information bottleneck.
We also show that by modifying the stochastic reference encoder to match the form of the true latent posterior, we can achieve high-fidelity prosody transfer, text-agnostic style transfer, and natural-sounding prior samples in the same model. The modified encoder also addresses the pitch range preservation problems we observed during inter-speaker transfer in our past work.
Lastly, we show the capacity of the embedding can be decomposed hierarchically, allowing us to control the amount of sample-to-sample variation for transfer use cases.
To appreciate the results fully, we recommend listening to the audio examples in conjunction with reading the paper. <comment><USER2> When you post it this way we can't click on the link.

Just post a link to the paper and then we can discuss it.</comment>


Web application development workflow with Node.js and Git - <AUTHOR> https://gelnior.wordpress.com/2011/12/27/web-application-development-workflow-with-node-js/

<comment><USER2> Hmm...I normally start with backend and do the UI last, since the backend it's then easier to add features on a whim.

Is it common practise to do the UI first in some parts? Does this not cause problems when certain features get dropped?

<comment><AUTHOR> Before doing BDD, like you I was working on backend first. Since I experiment BDD, when I work on backend, I have switched my mind from "what could be useful ?" to "what is really needed ?". Writing UI first helps me to find the answer.

I am not sure that writing UI first is a common practice, but it fits good with development of web application which relies a lot on UI.

</comment></comment><comment><USER3> Why do you emphasize Git in the HN link? It seems you use several key technologies for the demo - Backbone, Coffeescript, etc. Git is just a VCS, so why did you feel it necessary to emphasize it?

<comment><AUTHOR> I emphasize it because Git changed a lot my workflow since I use it. Before that I was a SVN user and I commit only once I finished a feature (or sometimes several features...) and I almost never did any branching either. Perhaps that saying DVCS instead of Git would have been better.

<comment><USER3> I don't have anything against Git, but it just appeared irrelevant to the listing of technologies you used for the actual coding.

You could have branches with SVN too, by the way. And commit often. But you've switched to Git already, that's good. Stay there :)

<comment><USER4> I appreciated the explanation of how he uses git in a workflow. Everyone does things differently and DVCS is not just "another VCS". Treating git like you would treat svn is a recipe for heartache.

</comment></comment></comment></comment><comment><USER5> Awesome! I have been looking for some best practices for merging all of these toolsets. One thing that continues to escape me, however, is building a succinct directory structure for JS applications? I cannot seem to wrap my mind around the exports idea...

<comment><AUTHOR> Yes, I had the same problem. Ponyo (example application) code on github can give you some hints, I tried to make things clean and as light as possible. <https://github.com/gelnior/ponyo>

For client-only JS applications, have a look at Brunch framework. It is really good to structure your app (Ponyo client side is based on it). <http://brunch.io/>

</comment></comment><comment><USER6> UI first: also called "top-down" design.

</comment><comment><USER7> <https://github.com/gelnior/ponyo> npm install coffeescript

should it be : npm install coffee-script?

<comment><AUTHOR> Thank you, README is good now.

<comment><USER7> need add one more line: npm install stylus

plus, as a quick test, it did not work for me, i.e. after I enter a category, then press 'add', nothing happened.

<comment><AUTHOR> Did you install mongodb ?

<comment><USER7> you're right, now it works. thanks!</comment></comment></comment></comment></comment>


Why Tufte is Flat-Out Wrong about Pie Charts  - <AUTHOR> http://speakingppt.com/2013/03/18/why-tufte-is-flat-out-wrong-about-pie-charts/ <comment><USER2> > _But what if, instead, the only point you want to make is that the 2 largest > distributors control 65% of the market. Which graph demonstrates that more > clearly?_

Apparently, the OP has never heard of stacked bar charts?

<comment><USER3> Or simply writing _"the 2 largest distributors control 65% of the market"_.</comment></comment>


Why Publishers Don't Like Apps - <AUTHOR> http://www.technologyreview.com/business/40319/?p1=BI <comment><USER2> What most people don't realize is the massive disconnect present in any current newsroom. In one corner, there's the print staff, in another the web staff. They work in separate systems, follow different workflows and are treated like different P&L centers. Couple that with the very conservative organizations that print papers are and you have a recipe for infighting and 'Tinker Tailor Soldier Spy'-like power games.

There's currently a major push in the industry towards what's generally called the 'convergent newsroom', bringing print and web together under one roof, so you have a 'Sports' department that's in charge of sports regardless of channel. The tablet has in many ways acted as an accelerator in this process, in a roundabout way. When the tablet arrived, as the author noted, the print people relished the opportunity to find a digital way to go back to olden times. On the other hand, the web people saw it as a natural extension to the website. So massive infighting will have occurred at most newsdesks around the world. Since the print people have the most clout in most newsrooms around the globe, they generally won the initial round, which pushed the print people closer to digital. With the failure of early tablet papers (distributing massive, perfectly kerned pdf's to devices), the web people have gotten a shot at it, thus pushing the organizations closer to each other.

At the same time, the systems vendors, harrowed by the competition from open source sees the convergent newsroom as the strategy to win; None of Wordpress, Drupal etc can easily produce a website and a printed paper. The tablet has in many ways been a spearhead in getting newspapers to look at buying new systems and redesigning their organization around them, producing tablet, mobile, web and print in one system. So every enterprise sales force in the industry is out there pushing tablet systems like it's the second coming.

Newspapers aren't stupid, they're just (1) stuck in old organizational structures, (2) using software that treats different channels as silos, and (3) fraught with unionized contracts that make any change insanely difficult (some contracts stipulate that the editors can only work in specific versions of InDesign, for example). At the same time, they're very clearly on the losing end of the digital disruption as the ad buy withers away from them with nothing to replace it. No wonder they act like a deer in headlights.

</comment><comment><USER3> My strong intuition is that the era of apps as centers of profit themselves is going to be short lived.

People are going to get tired of the gimmicky games. Content-oriented apps are going to be easier to code as HTML5. Big companies like Facebook will probably still find value in building native UIs but the number of apps actually making money via sales in the app store is going to dwindle off.

<comment><USER4> Facebook ironically does not build real native apps, they are just beautiful HTML wrappers. FB apps are an example of user experience regressions, as they were by far snappier two years ago.

<comment><USER3> Yeah I'm aware of that but from what I hear they have native apps in the works.

Of course, if even Facebook prefers to build HTML apps what are the odds that smaller companies are going to go to the extra trouble and expense of native?

<comment><USER4> If you go the 80/20 route, you'll only need an iOS anyway, and later on you can add an Android app - that's what they all do now, anyways. Perhaps that will shift to Android-first when everybody and his dog has a cheap Android phone (I hope not!).

Pseudo-native HTML apps are inferior, and people will notice it. I'm quite fed up with the FB apps on both iOS and Android because they spend more time with loading than the in-browser version. It's so bad that I actually considered if FB wants to drive people away from mobile so they click more ads in the browser - I don't think that's really the case though.

<comment><USER5> Will people notice it -- and leave the app? Or will a few geeks complain.

<comment><USER4> Ask Apple if paying attention to minute details (which the average user does not mention) has paid off in the long term.

</comment></comment></comment></comment></comment></comment><comment><USER6> > But the real problem with apps was more profound. When people read news and > features on electronic media, they expect stories to possess the linky-ness > of the Web.

But why not simply embed a web view? I like to use the App "Alien blue" to visit reddit.com. This sites purpose is to link outside and it works fine as an app.

There is nothing wrong with apps, or even walled gardens, but the implementations of digital magazines shortly after the iPad release was a giant WTF: Glorified PDF Viewers, slow, non-hypertext-linky, non-zoomable, non-Retina-ready, crashy, 500MB - 1 Gigabyte an issue.

<comment><USER7> You have to also "simply" embed a download/update mechanism, "simply" test various restore scenarios (Consumable vs non-consumable receipts), "simply" make sure it works in various orientations, and "simply" modify the way the entire organization works to suit Apple.

The content is also different, taking a bunch of webdevs and telling them make this work on iOS does not result in compelling content layout, design, or navigation. There are subtleties in pinch&zoom, dragging, etc. that most webdevs have not had the pleasure? of dealing with.

On top of that, UIWebView bridging js+objc is a PITA for iOS, and its a major problem for android where the 2 solutions are not even close to similar. So there is little code reuse between the viewers, and the content itself must be slightly different for the 2 platforms.

<comment><USER8> Yep, sounds like 'work' and these people don't 'work'.

</comment></comment></comment><comment><USER9> Okay, couple of things here:

1) Just about every magazine app out there, that I've tried, is shit. I was happy to pay for Wired, because I love Wired, but the app was terrible. 500MB for a _mobile_ app, with 'interactive' features that belong on a 1990's giveaway CD-ROM from RadioShack.

2) 19% of ALL tablet and smart-phone users paying for news apps in the past 30 days is still a LOT of paying customers.

Magazines are known to throw stupid amounts of money at things, yet when presented with a new platform that could be the saving grace of their entire industry they said, "The guys who make our web banners could whip something up for us, right?"

It sounds like they're giving up without ever having really tried. And by having tried, I mean developed something that really embraces the medium and isn't just a dump from In-Design into some pre-fab 'app' engine.

</comment><comment><USER10> I disagree, but only based on personal observation. Publishers clearly love apps--hence the reason when I go to nearly any newspaper from the NYT to small town USA news asks me to add their iPad apps.

</comment><comment><USER11> tl;dr

publisher outsourced development and got garbage, puts the blame on "Apps"

lesson learned: Don't outsource your core business.

</comment><comment><USER8> What a troll! The problem is we have pedantic editors that do not want the text to flow fluidly. They want to control every extra dash like it is print. They need to realize that to work on landscape/portrait mode, you have to program the text to flow fluidly, you can't use 'screenshots of text'. Simple fact: the publishers are stupid.

HTML5 works the same in an App's Web View as it does in Safari, so the lies at the end of this article are particularly grating.

</comment><comment><USER12> Wow,

This seems like a pretty big correction to claims the wall-gardens are going to replace the Internet.

A single, free, multi-linked information space does seem inherently better than a series of print reproductions.</comment>