The Longflow Manifesto - <AUTHOR> https://github.com/Nax/longflow-manifesto/blob/master/README.md <comment><USER2> I know this was intended with a good heart, but it seems very naive to me. At times I have hated agile & scrum. I have hated interruptions, I have hated meetings, and I have hated deadlines. I've tried to explain to management that they were shooting themselves in the foot by adding overhead with meetings and status reports. With hindsight, I now believe I was wrong.

As an engineer, this sounds like bliss. Sit quietly by myself without interruptions and solve the problems of my choosing in whatever way I consider the highest quality. It sounds like grad school.

As a manager & business owner this sounds like a nightmare. Engineers who refuse to make & meet deadlines, refuse to communicate & report status regularly, and work on problems of their own choosing, it adds up to people I can't make very good use of, and work getting done that doesn't contribute meaningfully to the bottom line.

There's a reason you need regular communication: because people walk out of planning meetings with different ideas in their head, even when everyone thinks they agree. If you don't follow up often, nobody will get what they expect. Realizing that as a programmer, even if it's painful, that I need regular checkins in order to be more useful to the organization, that is something that didn't happen early enough in my career.

<comment><USER3> This is a perfect example of the cognitive dissonance in business.

The driving premise of capitalism is that various competing companies pursuing the bottom line will produce the best outcomes.

Yet here we have a case that shows this premise to be a lie. The engineer in your story wants to produce a quality product, a good outcome. But the manager in your story won't allow a quality product because it conflicts with his bottom line. The bottom line is directly at odds with a good outcome.

And sure, within the context of business there has to be a balance between seeking good outcomes and the bottom line. But to me, that means we should be seeking a better model than business, that allows better outcomes.

Maybe the Longflow Manifesto doesn't work in business, but maybe that is because business is wrong, not because the Longflow Manifesto is wrong.

<comment><USER2> I don't understand your argument, will you elaborate?

You're right the engineer and the manager have different agendas -- they always have and they always will. But I don't understand the logic that takes you from there to the manager blocks quality and bottom lines conflict with good outcomes and business and capitalism are wrong.

These are intruiging thoughts, and you might be right, but you're changing the subject and talking about global economic theory and philosophy along the lines of Hobbes and Marx and Smith. In the context of this thread, these are enormous leaps and are neither the only nor the simplest explanation here.

Can you cite some examples of companies with good outcomes unrelated to bottom line? What is a good outcome that doesn't involve the bottom line? How can a company even exist to produce a good outcome without a bottom line?

The problem with the manifesto and with your thinking here is that budgets are unavoidable. There are no jobs, no projects, and no companies with infinite resources. Placing quality over deadlines can never work for all companies, and cannot work for any company indefinitely.

FWIW, the premise behind capitalism is "an economic system based on private ownership of the means of production and their operation for profit." (Wikipedia "Capitalism")

The bottom line is part of the definition.

The Longflow Manifesto is written in the context of business, and I was responding in the context of business. If it doesn't work for business as you suggest, then you agree with me that it would be a bad idea for engineers working at their job to actually adopt this philosophy?

<comment><USER3> > These are intruiging thoughts, and you might be right, but you're changing > the subject and talking about global economic theory and philosophy along > the lines of Hobbes and Marx and Smith. In the context of this thread, these > are enormous leaps and are neither the only nor the simplest explanation > here.

I'm not making leaps to anything so large. I just want people to recognize that the outcomes business optimizes for are bottom line outcomes, not outcomes we would all agree are good. Too many people in industry believe that they're saving the world, which is only true as long as saving the world coincides with their bottom line (that is to say, not long).

> Can you cite some examples of companies with good outcomes unrelated to > bottom line?

Sure. RethinkDB produced a great data store--I'd argue the best out there.

Incidentally they aren't in business any more. Producing good outcomes that don't affect your bottom line is an inefficiency companies can't afford.

> What is a good outcome that doesn't involve the bottom line?

This is somewhat subjective, but I think there are lots of things we can agree are good outcomes. RethinkDB (the data store) is one--usable, reliable software is a good outcome. But RethinkDB (the company) made money selling support--if you want to sell support for a piece of software, there's no reason to make it usable and reliable because then people don't need support. IBMs software business is a great example: it's so crap it's unusable without support, but IBM rakes in the cash.

> How can a company even exist to produce a good outcome without a bottom > line?

It can't. You can produce good outcomes, but the gods outcomes you can produce are limited to those that help your bottom line.

> The problem with the manifesto and with your thinking here is that budgets > are unavoidable.

Within the context of a company, sure. Outside the corporate world, I'm not so sure.

> There are no jobs, no projects, and no companies with infinite resources. > Placing quality over deadlines can never work for all companies, and cannot > work for any company indefinitely.

This is all true.

> FWIW, the premise behind capitalism is "an economic system based on private > ownership of the means of production and their operation for profit." > (Wikipedia "Capitalism")

That's the definition of capitalism, not the premise. The reason we are told that we should accept and participate in capitalism is that it supposedly produces good outcomes.

> The Longflow Manifesto is written in the context of business, and I was > responding in the context of business. If it doesn't work for business as > you suggest, then you agree with me that it would be a bad idea for > engineers working at their job to actually adopt this philosophy?

No, whether you should adopt this philosophy depends on your goals. If you want to produce good results and don't care about making yourself or (more likely) your boss rich, you should absolutely adopt this philosophy. But if you just want to get rich, your best move is to _become_ the boss and persuade you're engineers that the Longflow Manifesto is some crazy unreasonable thing.

If all you want is to make your business succeed, not caring for good outcomes or personal gain, then sure, keep working as an engineer and do whatever your boss tells you. I just don't think that's what most people want.

<comment><USER2> > I just want people to recognize that the outcomes business optimizes for are > bottom line outcomes, not outcomes we would all agree are good.

Okay, yes, I agree with that completely!

> If you want to produce good results and don't care about making yourself or > (more likely) your boss rich, you should absolutely adopt this philosophy.

"Think long term" and "always learn things" and "aim for high quality" seem like platitudes, not a methodology or a serious philosophy. What, specifically is the problem being solved here? Where is the evidence that what is said here has actually worked? What does this document say that will actually help me achieve high quality? What is it suggesting we engineers do that we aren't already doing?

I've never known an engineer in my life that didn't already think he or she was solving the longer term problems that others couldn't see or appreciate. One of the biggest problems we have in software is over-engineering.

Interesting argument that if I don't buy into this "manifesto", then I must not care about good outcomes or personal gain. I don't buy that, I don't believe Longflow provides me with the formula for either good outcomes or achieving personal gain or satisfaction. It claims to, but it delivers something else.

Purely from an engineering perspective, I don't believe that this Longflow essay offers me any _practical_ steps to achieving high quality, and I do believe that it contains some very bad advice; avoiding regular communication with management and avoiding budget discussions will both result in poor quality software and a failure to achieve either personal satisfaction or career growth as an engineer, in my experience.

<comment><USER3> > One of the biggest problems we have in software is over-engineering.

Again, this is dependent on your goals. If your goal is just to make a quick buck, any well-advertised shit will do, so any engineering you can cut out is waste.

But for my goals, I strongly disagree. The most widely-used front-end language lacks an integer type and has laughable security. MongoDB, a data store which requires replication not for scaling, but to maintain uptime when instances memory leak and crash, has a significant user base. The latest Macbook Pro sacrificed performance for a touch bar with questionable urility. Massive sections of our industry are built on sand. Over-engineering isn't the problem, under-engineering is.

> avoiding regular communication with management and avoiding budget > discussions will both result in poor quality software

What do these contribute to high quality software?

</comment></comment></comment></comment></comment></comment><comment><USER4> This is nostalgic to me, because it's reminiscent of how I thought about business and software about 10 years ago.

I got some very good advice from a more senior developer sometime between then and now that I repeat to all people starting their careers in any field:

"Just do the work," he said. "Don't spin your wheels on what's broken or what could be improved, just watch and listen and do the best you can with what you've got. Just _do the work._ "

It might seem condescending or patronizing to hear. I was angry for a week after I heard it: _what right does this asshole have to tell me what I should or shouldn 't do, it's the company that's a trash fire and I know better!_ But only by understanding why things are the way they are, and who else is connected to each part of your work, will you start to see that there are damn good reasons, even if the result feels inefficient or frustrating at your desk. That understanding and empathy will guide you to better solutions.

In here is repeated several times: "think long term." I agree. Play the long game on your career, too. If you care about changing how your company works—how any company works that you're a part of—put in the time, do the work, build trust with the people around you, and grow into a position you deserve, and one that you can do good with.

Yes, everything's broken. That's true at 90% of companies, and in the remaining 10%, only _most_ things are broken. Brush it off. Water off a duck's back. Do the best work you can with what you've got.

[http://www.trisweb.com/poetry/tobeofuse.html](http://www.trisweb.com/poetry/tobeofuse.html)

<comment><USER5> > But only by understanding why things are the way they are, and who else is > connected to each part of your work, will you start to see that there are > damn good reasons, even if the result feels inefficient or frustrating at > your desk.

I would go a bit further, there isn't necessarily damn good reasons, sometimes there is just politics, and if you would like to keep your job, do not try to fix something (unless you have been given orders to do so) if there is _any_ sort of politics involved, unless you've been there long enough to know with absolute certainty that it is not a politics driven organization. And of course, every organization thinks they are free of politics, or doing things wrong, or dishonest employees, etc. Politics trumps _everything_ , even economics.

<comment><USER4> In other words, _how people feel_ about their position and their contributions trumps everything. Politics is just relationships and emotions. Yet another argument for building empathy and getting to know who cares about what.

<comment><USER5> I might say how _those with power in the company feel_. But not sure I'd say it's "just" that, it can mean the difference between dismissal or criminal charges vs a promotion in extreme cases, so not something to underestimate.

</comment></comment></comment></comment><comment><USER6> No offense intended to the author, but it sounds like they've mistaken the purpose of their job. For most engineers, their job is _not_ to produce exceptionally wonderful engineering.

It is to produce whatever god-forsaken clusterfuck is required to get the product out before the holiday rush. Or more generally to do whatever the business needs to do in order to keep making enough money to continue existing.

If engineering doesn't directly serve business goals, maybe that business doesn't really need that engineering department.

<comment><USER7> Producing whatever god-forsaken clusterfuck is required to get the product out before the holiday rush only serves business goals in a very unlucky or very badly run business.

A properly run business cares about selling products tomorrow but also cares about selling products next year. A properly run business therefore invests time in quality engineering so that the products they build now still work next year, or can be easily modified to fit whatever next year's requirements are.

It's just good sense. Rushing out a horrible bodge job is only okay if you don't plan to be in business _after_ the holiday rush, or at least not the same business. Otherwise, if you're doing the minimum viable work to keep the company ticking over from day to day, you'll usually find that the quickest way to do it today makes for more work tomorrow when you have to undo whatever horrible kludge made it work.

There's a quote I like from Dave Thomas, one of the original codifiers of "Agile": _When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier._

<comment><USER8> If that cluster is profitable it serves business just fine. If you can prove poor system quality is costing money, explain that to management and they'll authorize spending resources on reactors.

<comment><USER9> Sometimes it just appears profitable. It may be adding all kinds of costs that can't be tracked. If it's a public release then it may be doing long term harm to the companies reputation.

<comment><USER10> OMG this. Technical debt amounts to an externality put on engineering by management, and it's all too easy for most to ignore the complaints of engineers. The solution is not (as others have proposed in comments here) to "just do the work" as that serves to bury ever deeper the cost being imposed on the future of the organization.

</comment></comment></comment></comment></comment><comment><USER11> Oh boy.

        > tired of the "Agile"/"Scrum"
        > bullshit.

Probably the best way to appreciate Scrum is to have worked on a commercial software product before it. Scrum exists to protect the developer. It explicitly says that estimates are inaccurate by their nature (estimating in story points, never time), estimating is hard and needs the intelligence of the team (planning poker), and the bigger the estimate the less likely it is to be accurate (fibonacci-ish estimate sizing). It allows developers to hide important tech debt removal inside stories by making stories explicitly stated in feature terms, and not in terms of items that a product owner can deprioritize. And it has a focus on making sure there's proper knowledge sharing (anyone works on any ticket, pair programming, dialy standups) so that you don't get a silo'd project where only one developer understands how one piece works.

<comment><USER10> I know it's a tired phrase (and borders on no true Scotsman) but most developers I've known to have the OP's attitude about agile development have never seen real healthy agile in practice. Plenty of companies these days operate somewhat iteratively, meet for daily scrums, and put on other trappings of an agile process. But they usually fail the muster on every one of the agile preferences, particularly the "working software" one and the "responding to change" one.

</comment></comment><comment><USER12> > In the software development world, it is impossible to produce meaningful > estimates, let alone precise ones, for anything but nano-tasks.

Why is the notion of this repeated so often? It's not _impossible_ to differentiate between tasks that take a few hours, a few days and a few weeks, where such estimates are useful enough to make business decisions (e.g. how much to charge, if the time/benefit is worth it). Sometimes you'll go over and sometimes you'll go under in your estimate but an estimate is meant to be a ballpark figure to help make decisions. I track my estimates and actual time when bidding on fixed price projects and I don't find it hard to be pretty accurate; of course it helps if it's a project that's similar to something you've done before though.

To put another way, if a manager is trying to decide how much to charge a client for a project or is trying to decide which of two new features has the best cost/benefit ratio, what do you expect them to do if engineers can just say "I will not provide any estimates because estimates are impossible"? Every industry uses estimates and estimates are expected to be a ballpark figure only.

<comment><USER13> Some anecdata: I also used to believe estimates were nigh useless. This quarter we made a serious effort to estimate the work involved in each task, across a team of 5 people–so a total of roughly 50 person-weeks of work, broken up into tasks of 1-6 weeks. And this was for a project that involved building a new product, using a lot of technologies we hadn't used before.

 _Almost every estimate was on point._ There was one task estimated at 3 weeks that took two days, and one two week task that took 5. Other than that, every estimate was within a week.

Now, I definitely think that we got lucky in some significant ways, and I wouldn't bet on being able to achieve the same level of accuracy next quarter. But I'm a lot more optimistic about the possibility of estimates than I used to be.

<comment><USER12> > Almost every estimate was on point. There was one task estimated at 3 weeks > that took two days, and one two week task that took 5. Other than that, > every estimate was within a week.

Exactly, and in other cases you'd have a 5 day estimated task that took 2 weeks but given enough estimates the high and low ones should roughly balance out.

If estimates are always widely inaccurate there's a big problem somewhere.

<comment><USER14> Yes there is a big problem. Managers reducing all estimates in the hopes of looking professional and thus getting a raise from a higher-level manager, making the programmers' lives a living nightmare in the process.

It's the same problem 99% of the time.

</comment></comment></comment></comment><comment><USER15> Although the points in this article appeal to me, as a software developer who would gladly take all the time in the world to work on a problem for as long as I want, the world simply does not work that way.

The words 'money' and 'economy' are not present in the text. The writer does not seem to realise how his/her salary is paid. A problem does not exist in isolation. It exists because after the problem is solved someone is going to (or expects to) make more money than before the problem was solved. The solution to the problem is only viable if the cost of solving the problem does not exceed the economic benefit of the solution. This longflow methodology does not provide any way to manage those costs.

<comment><USER16> > as a software developer [...], the world simply does not work that way.

Well, the world is not a software developer, so hard to argue what would be if it was. Or your grammar was off.

> [being] a software developer who would gladly take all the time in the world > to work on a problem for as long as I want, [...]

"Taking all the time" to "work on a problem" is _so boring_. I would get fed up with the problem after a quarter. "The problem" is actually a fractal of things that need to be done before a perfect solution arises, and I've seen many such fractals of work.

Fortunately I'm a half-programmer, half-sysadmin, what results in me writing tools for fellow sysadmins. Such tools are very, very rarely larger than a dozen KLOC, so I tend to jump between problems and runtimes and languages quite often compared to regular programmers. It's so refreshing to write Perl after an Erlang application, to update shell script after writing a C library, or to debug Python module after designing a network protocol, or to analyze firewall behaviour after writing a Ruby plugin for data router daemon.

Time constraints (realistic ones) give some framework to work with. They are a good thing, if not abused. But the same stands for any other type of constraints (memory, disk space, response time, specific runtimes that are already present on target system, system's autonomousness, application's transparency and monitoring, etc.).

</comment></comment><comment><USER17> This is a pipe dream. And I say this as a developer, not a manager or business owner.

In particular:

> Estimates are to be avoided at all cost.

How is an executive supposed to decide what I should work on next if I don't provide estimates of the things that I could work on?

Besides that, I wouldn't like it if I asked when I'd get my next paycheck and the response was, "You'll get it when you get it. Leave me alone."

<comment><USER7> > _How is an executive supposed to decide what I should work on next if I don > 't provide estimates of the things that I could work on?_

I dunno.

Maybe ask an executive at one of the many companies that have scientists or mathematicians on staff how they do it.

<comment><USER17> Those folks are probably working in a research lab, though, not in product development. And few companies these days have that luxury.

My father has been an engineer (not in software) for decades. I haven't asked him about this yet, but I'm guessing he has to provide estimates for his projects.

<comment><USER18> There is a very big difference between a software "engineer" and a real engineer. I personally think that picking the word "engineer" to describe our profession does us more harm than good.

<comment><USER17> There is indeed a difference, but I don't think it makes us software developers look very good. Shouldn't we at least aspire to the same level of professionalism and quality that good engineers have achieved?

<comment><AUTHOR> My father is a mechanical engineer and he says the amount of problems in the designs he reviews is very high, contrary to popular beliefs. There are often multiple rounds required to clean things up and some problems are discovered at build time. Buildings and bridges are not falling down because they are much less complex and more similar to each other than software projects.

</comment></comment></comment></comment></comment></comment><comment><USER13> My approach might be called "Risk Driven Development"–the idea is to view software projects as a process of iteratively reducing uncertainty, and to structure your workflow around mitigating the most important risks. Agile is a special case of this, where the main risk is subtle details of customer requirements, but many times this is not the biggest risk in a project. I manage a data science team, and this is almost never our main risk. Instead, we've had:

–Technology risk: the project requires new libraries, some of which may be immature or have show-stopping bugs. You want to identify these by building PoCs quickly, and switch to alternatives early if needed.

–Assumption risk: one project focused on taking a statistical algorithm that was producing "ok" results, and making it better. We assumed that this mostly involved fixing the algorithm. However, the algorithm's performance was actually quite good, and most of the issues were caused by downstream bugs. We would have saved several weeks if we ran some quick tests to verify this early on.

–Coordination risk: if you have a lot of engineers working on different components of a project, you need to make sure those components mesh well together. I usually try to specify the interfaces of each component in great detail before any work starts, e.g. specifying all the columns in a table, or lots of types in code.

–Data size risk. With distributed systems, often you have a system that works on 10gb of input and fails on 100gb. This is usually due to some piece of code that's convenient but not performant. Thus you want to test with large datasets early and often, so that you don't end up baking the convenient but not-performant patterns into your project.

</comment><comment><USER19> I know that when I follow these steps I never produce anything.

I find that soft deadlines and breaking my work into pieces at least gives me some idea on how long something might take and when to start making compromises.

Just because estimates aren't 100% accurate doesn't mean they're 0% useful.

<comment><USER14> I agree, but this only applies to a certain group of people -- to which you obviously belong.

I used to need supervision. I used to distract myself with all sorts of idiocies when given freedom and time. I felt better when given some clarity and a grander scheme, and pointed at where do I belong in it.

I changed this by a very rigorous self-disciplining process over the years. Now I realize requirements and the bigger picture before the product owners, most of the time anyway. Nowadays, if you leave me alone to work in peace and do _ZERO_ pokes in my general direction, you'll find that I can often times solve a week-long task in 2-3 days. Conversely, if you pester me several times a day, I might take 2-3 weeks.

It honestly depends on the individual. The manager has to be a good psychologist and find the proper ways of communicating with every single team member.

</comment></comment><comment><USER20> Time estimations is an industrial way of thinking applied to a post-industrial world.

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

In the industrial world the problem were already solved (machine was built, market often established and output depended on a few factors that could be calculated and adjusted. Need more output add more of X) In the post industrial world every project is about problem solving and scoping.

To put it into comparison.

If we apply post-industrial thinking to an industrial world. It means that each time a product needed to be done if not the factory, then the machines would have to be developed. It will take many many years before time estimation will die, but it will happen.

<comment><USER21> >It will take many many years before time estimation will die, but it will happen.

I'm not so sure. Typically the business isn't really asking for time estimates. They are asking for quarterly or yearly spend estimates. Since the primary cost driver is IT timesheets, they converge. At least at non-tech companies, that's never going to disappear.

How much revenue will this project create, and how much investment/expense will it need (within specific time boundary x)?

<comment><USER20> Sure but those non-tech companies are most likely not post-industrially based. Technology is the big differentiator here. I am pretty sure what we will see sooner or later is some sort of continues development where the idea of estimate makes no sense only rushing towards being the first who solve problem X. If you think about it thats a much stronger position as long as there are enough money to pay for it. Companies who can't wont be able to survive IMO.

<comment><USER21> I see what you're getting at. The opposite happens as well though. Plenty of companies don't survive specifically because they chase problem X until there's no money left...rather than spending on a sane risk/reward curve.

</comment></comment></comment></comment><comment><USER22> This is all fine and dandy, but when the executives that should have little to no interaction with engineers (paraphrasing) are also the ones approving the budgets and cutting the checks to fund projects, you kinda have to respond with estimates/budgets/timeframes on when they can realize some ROI on their initiatives.

I totally agree that agile can go wrong a million different ways, and sprints can often lead to scrambling at the end of them if not managed well, but those are all process failures and should be fixed by the Product Owners/Scrum Masters whose job it is to balance out workloads and fight to manage realistic expectations.

Just because things can feel rushed and stressful doesn't mean you need to jump to the other end of the spectrum and fight for no estimates and no progress checkpoints. There needs to be someone pushing for delivery of value at all times, otherwise you'll end up with devs building beautiful things that no user gives a fuck about.

</comment><comment><USER23> I like it, but it could use some refinement. Already a couple of years ago Dave Thomas, one of the original authors of the Agile Manifesto, wrote a piece called "Time to Kill Agile" (renamed "Agile is Dead")[1]. The "lean startup" methodology and guidelines found in "Rework" and "Getting Real" have gotten traction in some of the younger companies in my area but I don't think they've been codified into a single set of guiding principles that could work well for larger enterprises. It might've been nice if Dave Thomas had proposed an additional point or two on the original Agile Manifesto to correct some of the problems he mentions. But it's hard to turn the Titanic around and it seems like "correctives" to belief systems generally come in the form of a competing system that asks you to discard the previous one.

1\. [https://pragdave.me/blog/2014/03/04/time-to-kill- agile/](https://pragdave.me/blog/2014/03/04/time-to-kill-agile/)

</comment><comment><USER24> Sometimes I have this dream vision of a software company were the only management tool is a huge board of git commits with clear commit messages. The small team meets at the beginning to set the goal and timeline. All code gets reviewed by multiple people and every programmer knows the rough project status by looking at the git-board and is actually eager to try the product each morning since everything is CIed. The only time meetings are called is when someone realizes they are in over their head and needs help or if they feel they'll need longer than they thought.

Just a big newsfeed of git commits and everyone can magically understand how it all works together. You stroll into the office and look at the board and see the 24 commits since you left and all the changes immediately inform how the product has changed in your head. You play around with the product in awe, brew a cup of coffee and read over the great new sorting algorithm that john committed a couple of days ago, smile, crack knuckles, ready to rock and roll writing whatever you write.

<comment><USER25> I believe this works very well and is what I would propose for a small team (5-8 engineers) working on related things (let say your typical react+node+mongodb stack).

I don't think this scales beyond that. Even with a small team it's not realistic to expect your engineer to understand both the commits in the iOS frontend, the golang backend and the AWS terraform templates.

But your comment makes it clear that we should define where such workflow should be applied. One size won't fit all, especially on this regard.

</comment></comment><comment><USER26> "In the software development world, it is impossible to produce meaningful estimates"

As a manager and sometimes-coder, I know this to be untrue. It _is_ true that you can never know _precisely_ how long a given task/feature will take. But an experienced developer who isn't coming in blind to an extant project can certainly divide tasks into a few rough buckets: trivially easy (less than a few hours of work), very complicated (could require several weeks or more), and in-between.

Those are meaningful distinctions! That kind of very rough estimate is _incredibly valuable_ for planning. If I know which tasks are hard and which are easy and which are in between, I don't need to know _exactly_ how many man-hours they'll take - rough estimates let me allocate resources and set priorities pretty darn well.

Besides: managers are optimists, and in the absence of information to the contrary we will assume everything is easy. :)

<comment><USER27> The problem isn't estimates. The problem is in turning estimates into deadlines.

An estimate is probabilistic. There might be 50% chance I can get it done in a week, 70% chance I can get it done in two weeks, and 95% chance I can get it done within the month.

That is great for long term planning. However, if you use that to give me a deadline of two weeks then there is a good chance I won't deliver. This kind of pressure is toxic.

<comment><USER26> "This kind of pressure is toxic."

Agreed. But that is a problem of bad management, not an inherent problem with making estimates. And bad managers gonna manage badly, whether or not you give them estimates of how long tasks will take.

</comment></comment></comment><comment> tony-allan I like the idea but projects and products need to be planned and funded.

The manifesto must address how a business can create a budget and timeline for a new product or service. Without these, sensible business decisions cannot be made and the business will not make money.

Will the software cost $1 million or $10 million? Will it take six months or two years to introduce? Will it have features when they are needed by the customer?

</comment><comment><USER28> These are good ideas but they need to be fleshed out more. A lot of younger engineers don't clean up their codebase simply because they don't know the principles of clean code or good OO design. A pairing process with senior engineers seems worthwhile, among other teaching processes, but they aren't given much attention.

</comment><comment><USER29> The Scrum framework and Agile manifesto have been designed and purposed to remedy the very conditions the author is complaining about.

I suggest reading up on some of Jeff Sutherland's writings and books on how he created Scrum and the reasons he did so.

IMO there's a good chance the Longflow manifesto might be better formed after doing so.

<comment><USER30> Diplomatically, and accurately, put. I say this as a dev and business owner.

</comment></comment><comment><USER31> I love the ideas, but I doubt the reality of ever getting this workflow implemented. I've been a professional developer for 17 years and exactly zero of the companies I've worked for would implement this process. Besides in research environments, is there any software shop out there doing this?

</comment><comment><USER32> This seems to conclude that estimates are often wrong (which is true), and then move to the idea that estimates aren't useful. This is wrong. So long as projects that are estimated to take a week typically take less time that ate estimated to take a month, they're still somewhat useful.

</comment><comment><USER33> It's really funny. To say the least.

The "Typical Implementation"[1] is EXACTLY how a mature agile team behaves. The only difference is that business decisions are delegated to the PO when the devs DON'T have the whole business knowledge (if they do, then yeah they can make the call by themselves, but that's NOT where most companies stand for!).

It's pretty common for a company that is not technology focused on having a PO to decide priority, make the call if a task is unneeded and decide if things engineers learned (called spikes) will change the business priorities and will make you go back to step 1. The difference is that you need communication skills, something most people lack.

Source: I am doing consulting for a year in the best tech team of a multi billion dollar Australian company that had a dysfunctional team and now it's crazily performant. The team is the least bug producer of the whole company. It's like working from 09:30 to 17:30 with 2 hours interval and still produce astonishing results. Sorry for the ad verecundiam[2].

[1]: [https://github.com/Nax/longflow- manifesto/blob/master/README...](https://github.com/Nax/longflow- manifesto/blob/master/README.md#a-typical-implementation)

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

</comment><comment><USER34> The author could spend some time discussing the genesis of the current, objectionable approach and what benefits it may have. It probably has some. Similarly, they might ask themselves:

* What are negatives or risks others might see in their approach?

* What are ways to mitigate these dangers?

</comment><comment><USER35> There is a lot of variance around Scrum.

How it is interpreted, implemented, and to which extent it is used... and results. Yet, everyone claims to be doing it correctly.

And when the success of a process is statistically not any different than random chance, then I start having skepticism about it.

I think Scrum oversimplifies software engineering and reduces performance into a single metric: velocity.

Do you have 3x more velocity but create 500x more bugs than the rest of the team? This is the same as saying you are trashing a project... but instead, let's promote you, because we care about velocity and rarely keep track of issues attributed to a change.

Software engineering is a serious discipline, stop trying to oversimplify everything into color post-its and velocity. The only one benefiting from that is 3M and unethical people.

Instead, track the backlog size, and see how many tasks were created due to a defect in another task. Trading problems is not the same as fixing problems. Tech debt implementors trade problems, they don't fix them... This cripples projects while looking excellent in the burn down chart.

Otherwise, audit code bases. Send someone with strong technical skills and attention to detail to ensure quality and report on the team, and use that as input for rewards, rather than just velocity.

<comment><USER14> Absolutely.

What breaks my heart is that many managers to this day love their charts with imaginary increased productivity percentages and reduced average time spent per ticket, much more than they love reality itself.

It's like the market for drugs -- as long as there's a need for them, there will be market for them, legal or otherwise.

Conversely, as long as there are managers eternally in love with charts, there will be developers lying to them that these over-simplified charts represent reality.

</comment></comment><comment><USER36> I distrust any engineer who writes quality is infinitely superior to quantity.

<comment><USER37> Why? Obviously this doesn't apply to everything, but given that the marginal cost of another copy of an application is zero, it does seem to apply to software.

<comment><USER38> Because "good enough" usually works just fine. Also because navel-gazing doesn't get anything done -- projects stagnate and rot and often disintegrate entirely when they don't ship in a reasonably quick time-frame. If they do make it out, they're often clear bastardizations that aren't useful to anyone but somehow escaped the dungeon of development hell. To avoid this, ship early and ship often.

Just look around. The computing world is not designed by committee (although there's no shortage of pontificators and committees trying to pretend they're relevant). Someone makes a quick draft and throws it out there. People see potential, adopt, and then mutate/improve upon whatever building blocks help them attain their goals with the smallest amount of effort (NOT which building blocks best comprise their concept of an ideal project).

JavaScript is a great case study that demonstrates this very well.

<comment><USER39> JavaScript is a great example. It was hastily thrown together, not well thought-through, and didn't wind up being a substantial competitive advantage for its corporate owner Netscape, which is now defunct.

But we are still suffering from the aftermath. I wonder how much better the web coding world would be if Brendan Eich had been able to spend 60 days on it instead of the 10 was given?

<comment><USER38> Yeah, I absolutely agree that we've felt the sting of JavaScript for far too long, but the fact that it's so hard to replace only _further_ demonstrates the point. People are optimized to expend the smallest amount of energy necessary to reach a certain point. Unless a new client-side scripting language comes out and enables something that practically everyone, even non- programmers, wants and wasn't reasonably doable before, JavaScript is here to stay.

Meanwhile, committee-designed projects like Dart have floundered and ultimately failed in their ambitions to bring a better client-side scripting language to the web, despite the backing of the largest internet company on the planet.

</comment></comment></comment></comment></comment><comment><USER40> This manifesto had to be written as a formulated statement of a pure developer.

But it probably can not be used as a manual for the software developer in a larger organization, because it puts the software developer out of context.

A good software developer should always act inside his/her envronment and take all stakeholders in the software into account: the ones actually developing, the ones coming up with ideas on how to develop, the ones coming up with ideas on how to sell the developed stuff, the ones trying to check if the developed stuff is working and so on. A good software developer does not only understand the limitations he/she has to cope with but on an abstract level also those affecting the other stakeholders. Only if one understands the system one can work most efficiently inside of it. So, to all developers, learn a bit about management, about marketing, about selling and testing.

</comment><comment><USER41> Re-read the Agile Manifesto from time to time. It takes under thirty seconds.

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

</comment><comment><USER42> I think this is a great manifesto that would produce amazing software. I'd also never hire anyone who used this manifesto unless I've personally known them for years, and even then, the number of developers I'd trust with this manifesto is in the single digits.

<comment><USER14> Trust-based relationships provide the best middle- and long-term benefits for both sides. You're right it's an extremely rare occasion to find an honest mutual relationship of this type however.

</comment></comment><comment><USER43> While I think this particular sketch isn't going anywhere without a lot more work on concrete implementation details, I do believe it is well worth spending time on what a working formalism of development would look like built atop the first principle of "there are no estimates".

No existing methodology in practice works like this.

If you asked developers why this is the case, they would point out that at the high level, business deals are made in the shape of pay X for Y by time Z, while at the low level managers carry out the same internal deals of deliver Y at cost X by time Z, whether day by day or project by project.

Nonetheless, I agree with the basic idea that estimates in software development cannot be given with any reliability at all. The corollary there is that the client never receives what they asked for in anything but the high level sense. Every single deal is basically a polite fiction that is renegotiated at length all along the way.

Given that this is already the case, and people kludge their way through to make a business of it, whether kludging at the large scale with waterfall or kludging at the low level with agile, one has to imagine that there is a distinct, different way to actually surface and incorporate the absence of estimates top to bottom in the process of business and development, and thereby reduce friction and waste.

</comment><comment><USER44> Is turnabout fair play? Would he make his next paycheck contingent on whenever he gets around to shipping something useful? The company would pay him when the company benefits from his work--not before.

That's called "piecework", and I suspect he wouldn't go for that kind of deal. I suspect that he wants to get paid regardless of whether he ships or not. Why? Because his mortgage company and his grocery clerk and his power company are peculiarly unresponsive to the suggestion that he only works on "medium to large sized meaningful tasks" for which it is "impossible to produce meaningful estimates".

He is asking for a company to be his patron, with him as the artist. If he can get a job on the basis of the Longflow Manifesto, then more power to him. He's obviously passionate about his craft, and I respect that. Unfortunately, the company has ongoing expenses to pay just like he does, and from his manifesto, I doubt he gives two hoots about that.

We are not playing games here. Money is at the root of every big coding project--the really fun and important stuff, the stuff that makes you grow as a programmer. You want to play in the big leagues with us? Come on up. But I warn you: you must ship.

Of course I want you to learn. Of course I want you to not ship crap. But you and me and everyone else must find a way to do that and SHIP, my friend, and we MUST do it in weeks rather than months. Because that's how the company can survive, compete, and ultimately afford to pay for your chair and your bagel. In the LONG term.

</comment><comment><USER45> No, no, no. Management needs to know what the hell the developers are up to and for that they need _data driven_ accountability and transparency. That means they have to have some idea, _up front_ of the size of tasks and stories and have updates _on a daily basis_ of your progress on what's important. This is why scrums, sprints, and estimates exist. Suck it up, man up, and for God's sake show up to stand-up on time.

</comment><comment><USER46> One the problem with estimates are the unknowns, things that you don't know that you don't know. The other one is the balance between abstract and concrete: abstract definitions of a problem are quicker to write but slower to execute, concrete definitions are slower to write but faster to execute.

When you are asked to estimate something you have to load this definitions in your mind and project an outcome in the future, take in consideration known unknowns, and the chances of unknown unknowns. This takes time and it's not guaranteed to be accurate but the business needs it, to adjust other decisions (associated marketing campaigns, etc)

I don't have a solution but I found useful to be aware that the closer in time and smaller you plan is the easier to make concrete definitions becomes.

IMO a 3 month plan it's necessarily an abstract plan, for small companies at least. I think the team has to learn to meet the abstract goals, while being flexible in the concrete actions.

Example:

Your company plans a "AcmeBook with touch bar by Feb 2017", and all the marketing campaign is going to be created, to be ready for the deadline, the ads are not going to include technical details like resolution, sensitivity, multitouch. The ad is just showing that you can choose a emoticon. The sweet spot would be if developers could understand what the business is selling and communicate "we can meet that result with X internal features and Y quality." And the business understand the quality compromises that are going to be made in the worse case scenario.

So worse case you get no multitouch, no developer API ready, and no slider component (cancel the DJ demo!) but the most important, picking a emoji works! And it meets the abstract goal "AcmeBook with touch bar by Feb 2017" the rest can be improved in coming iterations.

<comment><USER47> You can plan, design, and engineer around things you don't know. Civil engineers have been doing it for a while now, maybe we should keep notes.

<comment><USER14> Civil engineers don't have to reinvent 50% of their craft every several weeks when yet-another-new-form-of-concrete is invented however.

Their craft is for the most part very static, well known and well documented. It's only up to the particular man/woman to be well-versed professional.

In the modern programming you work in constantly changing conditions and you have to be on the loop of the latest changes even if you don't incorporate them in your work.

<comment><USER47> You can't say we reinvent our craft because at this point all we have is some vague empirical ways of pseudo-sciensing the shit out of everything. We don't invent yet-another-new-form-of-concrete either, but we do constantly rewrite our tools because apparently we can't stick to a good way of organising them that has worked for us in the past, we constantly lay abstraction upon abstraction with no second thought (web dev frameworks, everywhere!), and we provide half-assed, incomplete, untested "tools" for everyone else to colour up some bar on a mildly popular website.

Software development is not engineering, at this point, it's fashion. That's nothing to be ashamed of. Fashion has been developed and affected even mathematics. The difference is mathematicians had already figured out a solid, rigorous foundation for their work that allows them to indulge in fashionable techniques and tools. We haven't.

This is all irrelevant to the point I was making, though. :-)

<comment><USER14> Semantics, my fellow human. ;)

What I meant is that each week/month somebody wants us to think differently about age old problems. It's not exactly helping matters, I think most of us will agree.

<comment><USER47> Totally agree, and it's useful. We need people to challenge established assumptions from time to time.

</comment></comment></comment></comment></comment></comment><comment><USER48> We need to unify this with actually hitting deadlines/making it economically viable, at least until basic income is a working model.

Maybe tie it so that every stage has a payout (20% ln start, 80% on finish or sth like it). First stage ist planning the project, in two stages: first has a fixed compensation based on headcount/"salary". This stage roughly estimates the scope and sets the upper and lower limit of budget. Based on this budget, the second stage does detailed planning, setting out as many sub stages as possible. This second planning stage is added on top of those stages, the total budget is divided between all stages and the first payout is done.

Like this, good planning is rewarded (teams with more stages get more frequent payouts) and there is still some pressure to deliver (payout) but even more to do good work (every stage depends on the previous ones to be doable quickly)

<comment><USER22> This concept implies that it's possible to discover all possible scope before starting a project, which is almost always not the case on any project of relevant scale. This is waterfall.

The notion of "you'll get the rest of the money when the project is done" is toxic and dangerous, and implies that you can know what done means before you even start, and it's an objective and finite finish line you are approaching.

The reality is that you should be investing capital into resources over time to build towards a goal, and at regular intervals you should ask the question "are we done yet?". The answer should be based on what you have, not what's left in your backlog. Otherwise you'll descend into a groundhog day loop of checking boxes and completing tasks you came up with months ago without evaluating if what you already have built is good enough.

<comment><USER48> > This concept implies that it's possible to discover all possible scope > before starting a project, which is almost always not the case on any > project of relevant scale. This is waterfall.

Difference would be that the team defines their own scope. But I see your point

> The notion of "you'll get the rest of the money when the project is done" is > toxic and dangerous, and implies that you can know what done means before > you even start, and it's an objective and finite finish line you are > approaching.

This one I concede fully

</comment></comment></comment><comment><USER49> I like how point 5 is just casually thrown in there:

> 4\. If I need to learn something to do the task, I go learn it.

> 5\. If I _want_ to learn something new, I go learn it too.

... okay. If that's the understanding you have with your employer, more power to you, but it doesn't have much relation to the rest of the suggestions.

</comment><comment><USER50> _Estimates are to be avoided at all cost. They create needless pressure, competition, and participate in a toxic witch-hunt of who is the less productive.

In the software development world, it is impossible to produce meaningful estimates, let alone precise ones, for anything but nano-tasks._

Perhaps this can exist in the academic world, but once you have customers and release dates, sometimes you have to work around the date rather than the abstract. Dates also provide motivation if they're not abused.

<comment><USER14> The fact that somebody _imposes_ deadlines on you doesn't magically change the nature of programming however. I agree on the realities of the world out there -- which still don't apply to 100% of it, by the way -- but what you're saying is that we should unquestioningly accept an artificial byproduct of the business world realities imposed on our craft, or am I misunderstanding you?

Communication is paramount. If there's no mutual understanding, the relationship will collapse, along with the software project.

<comment><USER50> Sometimes it can. Sometimes teams plan based on "How long does it take to implement these use cases?" Other times (more frequently in agile) it's "How many use cases can we get by date X?"

It's harder to commit to the first scenario than the 2nd, since the 2nd (in practice) implies that the date transcends scope so you can take items out.

<comment><USER14> In my 15 years of commercial practice, I feel that your 2nd scenario very rarely translates well to reality: most of the times you need to put some foundations in the code that would allow features A, B, C, D and E. Even if your Scrum Master is liberal and tells you "OK man, we don't have much time, put features A and B only", this doesn't change the fact that often times the _initial overhead_ of all 5 features takes the most time.

Outside of that, I definitely am in agreement with you.

<comment><USER50> I think we're on the same page. The world isn't black and white. It's a matter of accepting which constraint (scope, quality, timeline) is the dominant one.

</comment></comment></comment></comment></comment><comment><USER51> The core question here is how to ship quality software on time. This manifesto just seems to favor quality over shipping on time (e.g. "don't fear running late", "value quality over deadlines"). Sure, if you don't have to ship on a schedule then you don't have to spend as much time on estimates or prioritization or interfacing with management about it. Not necessarily the best strategy for all companies.

</comment><comment><USER52> How is this effectively not a bazaar-style Free Software development methodology?

Seems to me that project (and product) structure have a tremendous effect on the viability of this mode of management. A very high degree of modularity, in particular, possibly with different teams independently implementing specific modules, and choosing the first/best depending on particular circumstances.

</comment><comment><USER53> This comment is a reaction to lots of dysfunctions that I've personally observed at software companies that are highly deadline driven. Deadlines are often intended to drive focus and productivity but frequently have the opposite effect, and engineers often use them as an excuse to create problems we'll have to spend even more time to fix later.

</comment><comment><USER54> Seems like it is optimizing a workflow to maximize the happiness of the developer, perhaps at the sacrifice of other things.

<comment><USER14> Let's be honest -- yes, that's 99% true.

However, let's throw in the mix that happy programmers = better product. A happy dev will work overtime without asking you for extra money. A happy dev will open their Mac in their bed and do researches for things they have to implement tomorrow, 1-2 hours before sleep. A happy dev will only recommend you quality devs if your company needs more hires.

I understand some people are rubbed the wrong way by saying this, and proceed to argue that the programmers act like special snowflakes / gods / whatever else, but it's still a fact: having happy programmers (when your product and money depends on the quality of their work) is absolutely critically important.

</comment></comment><comment><USER55> > If the task turns out to be unneeded, go back to 1.

No one person should decide that a task is "unneeded".

Most items in this suggested workflow are actually attainable via SCRUM.

</comment><comment><USER56> I really like the idea of 'always thinking long term'.

I think there's a couple of problems here:

1) Estimates are essential. We need them, even if they are rough.

Most software is not _rocket science_. I like to think of software like 'construction' or 'plumbing'. Few things should be that-that complicated. Avoid complexity.

Would you hire a guy to build you a deck if he told you he had no idea how much time and $ it would be? Nope.

2) Constant interaction is essential. Why? Because 'failure to understand requirements' is the #1 problem in software - always. The 'devil is in the details' and sometimes the smallest details matter. So, I think it's more about finding the right level of management and direction shifting.

2) Sprinting. I've found that without some need to hit interim milestones, software can just 'go on forever'. We, as Engineers have a proclivity to 'over design' very often. We write tons of code to accomodate false notions of performance.

By 'sprinting' to meet a milestone we are forced to face the ultimate reality: _time_. After a sprint, I almost always recognize that several pieces of what I was trying to do are unimportant, and that other pieces are more important. Were I to have 'optimized' it would have been a waste.</comment>


Ask HN: If you had ready to use real time technology, what would you do? - <AUTHOR>

Building something like Skype, Google Talk, or even Twitter is hard to do right at large scale. What real time service would you build if the technology was not a challenge? <comment><USER3> Custom reality tv. Users pay to see a day/hour in the life of another user - possibly a celebrity, though other fun people would be popular - who wears a tasteful camera strapped to their head or neck.

Witness an afternoon as Michael Schumacher. What's life like as an Oxford student? My name is Joe and tomorrow I will go free running in the city - <USER2> me.

<comment><USER4> psst: justin.tv

Justin used to run around with a helmet camera and a laptop+ 4 bonded wireless modems in his backpack.

<comment><USER3> Madness! I guess my "idea" depends more on engineering advancements then. When I wrote the parent I'd just finished watching a series of the excellent Peep Show (filmed mostly via helmet cam), and I was thinking how I'd like to be able to jump into anyone's head and observe their life in that way.

<comment><USER5> Being John Malkovich?

</comment></comment></comment></comment><comment><USER6> I'd take on shipping. It seems to me that UPS could be in-part replaced with intelligent routing of people's ordinary daily routines.

<comment><USER7> Was thinking that exact thing yesterday when I had to go to the mall for last minute presents - had major crowd/chaos anxiety, turned and bailed. If Amazon could do real time shipping, it would be a miracle. Happily pay a premium for it. They could have distribution hubs in all major cities...

<comment><USER8> They're offering same-day shipping in major cities now.

[http://www.amazon.com/gp/help/customer/display.html?nodeId=2...](http://www.amazon.com/gp/help/customer/display.html?nodeId=200105970)

</comment></comment></comment><comment><USER9> As of right now, I can find out a lot of information about a company by paying for the data from a data provider like Bloomberg or Reuters. This data, however, should be free and well-organized.

I would like to build a search engine that indexes and organizes regulatory filings, investment message board posts, investment blog posts, the portion of a company's website dealing with investment relations, and economic news.

You input the company's trading symbol to bring up all the relevant information about the company. Furthermore, there should be an API so that people can use the index in their own applications. I have no idea where revenue would come from.

<comment><AUTHOR> Why is something like Google/Yahoo Finance not good enough? Apart from 10-K and 10-Q's?

<comment><USER9> Have you ever used Bloomberg or Reuters? Google/Yahoo Finance are far from useful for anything but an overview of a company. The service I am talking about would be aimed at more professional users.

<comment><AUTHOR> Yes, I have used Bloomberg quite a lot, although I spent most of my time with its painful API. I just wanted to get your perspective on what Bloom feature you'd like to see in a web site/search engine.

<comment><USER9> Well, to start, if I could get correlation data from Yahoo/Google Finance that would be a great. In addition to that, if I could get my hands easily on data concerning pending lawsuits, better industry data, and better regression tools (though this may tie in with the correlation data requested above), that would also be wonderful. Those are just a few key things that would be nice for equity. Also, the data concerning anything outside of equities is severely lacking in Yahoo/Google Finance.

</comment></comment></comment></comment></comment><comment><USER10> An automatic, voice based translator: talk in one language on one end (to an iPhone or something) out comes another language and subtitles in another :-)

One thing that's interesting about this is that it's not too far off. We have speech recognition technology, computer voice technology, and translation technology. They need to get better, and faster, but they're there.

</comment><comment><USER11> Nobody pays you money because you solved a technology challenge. Solve problems for people who pay money for solutions to problems.

Some time later, you may run into scaling issues. You can cross that bridge when you come to it. (Or you can pay other people to cross it for you.)

<comment><AUTHOR> I agree with you completely. My question is what would you build if the technological barrier of building a massive, reliable real time service was not there. Everyone is talking about the Real Time Web (even organizing conferences) but Twitter is the only near-real-time service that comes to mind.

</comment></comment><comment><USER12> I've thought about making a real-time forum: basically the same thing as an ordinary forum software, but with presence capability and posts happening in real time without reloading. Or, if you look at it in another way, it would be a chat room with persistence, result is searchable, possibly threaded.

The hope is that conversations in such a medium would be something in between regular chat and regular forums, and they could be compelling enough.

The technology is not a big issue for building this, the Tornado framework has a chat example from which you can start. Text messages are short, they can be kept in memory and saved to disk once in a while either DIY or using something like Redis.

<comment><USER13> You've just described Google Wave. However, I think there's plenty of room in this space to come up with alternate implementations and interfaces.

<comment><USER12> Yes, Wave has all the features, but seems focused on collaborative editing, rich media, send and synchronize individual keystrokes etc. - so I imagine a lot of the design decisions would be different.

I don't think I'm going to build it though - the type of forums I am interested in actually benefits from the perception that you have time to think through what you are saying.

</comment></comment></comment><comment><USER14> I'm not uninterested in building something like Skype, Google Talk, or Twitter because of the technical issues. I'm uninterested because I have no good ideas (or passion) about solving a significant problem with them.

There are lots of things I'd do if you gave me technology that does not really exist. Stuff like speaker independent speech-to-text that's as accurate as an expert human could transcribe. Or language translation that was as good as an expert human. Or almost anything that let me have the power of a human brain for free (no, not MTurk).

</comment><comment><USER15> One that solves this

[http://000fff.org/slaves-of-the-feed-this-is-not-the- realtim...](http://000fff.org/slaves-of-the-feed-this-is-not-the-realtime- weve-been-looking-for/)

</comment><comment><USER16> Text to speech so that I don't have to consume realtime data like RSS, Facebook, Twitter, etc. while actively using a device. I'm just gonna wait for Google or someone else to solve that one.

</comment><comment><USER17> "two chicks at the same time, man"

<comment><USER18> (for those who don't know the reference: <http://www.imdb.com/title/tt0151804/>)

<comment><USER19> Of course I know the reference. Sorry, but a downvote is no defense against a levity injection attack.

</comment></comment></comment><comment><USER20> AVATAR. Plug into a clone of me and watch him do everything I think.

</comment><comment><USER21> IRC</comment>


Devel environment tips, workplace tips & employee retainment tips - <AUTHOR> http://sites.google.com/site/yacoset/Home/development-environment-tips

<comment><USER2> I liked the PaulaBean reference at the bottom of the article. Brillant. <http://thedailywtf.com/articles/the_brillant_paula_bean.aspx></comment>


How to Move 8PB from NYC to SJC? - <AUTHOR> I have been asked to cooy 8PB from a customers datacenter in NYC to our Datacenter in SJC. I expect to start in 2 weeks and I want to be done 30 days later.
NYC dc is currently unknown (!).  I should learn this next week.  The data is a collection of files size 100k to 2MB Ave size 500k.
What's the best way to move it?
Options:
1 - Ship my storage servers out there.  24 core controller with 128g ram, SAS card with 2xHGST 60 disk 10tb JBOD and 40gig nic.  We use Freenas. I could ship it out, copy the data and ship it back.  I could either just ship the disks or the whole storage system.
Option 2 - aws snowball.  I figure I can get 3gbps based on testing so the copy would take 30 days.
Option 3 - aws snowmobile - overkill for this?
Option 4 - find 1 or more temp 10g or 100g circuits
Option 5 - run it through aws direct connect assuming I can get this at the east coast dc. I have high bw aws dx in the sjc facility.
Option 6 - something else?
Your thoughts suggestions recommendations and experience appreciated! <comment><USER2> If you already own the servers and can do without them, then that'll be a fast option for sure. That said, that's quite a bit to insure on the shipping (that's a quarter to half of a million $ of discs alone?). Hate to think of the damage if one of those servers were dropped. Plus you're shipping twice, so that's double the cost.

You can probably do via tape for circa $50k. Probably a lot less if you buy in bulk. Also depends on the kind of compression you can get on that 8pb.

If you can handle tape (500-1,000 tapes is a lot to do manually), I'd consider shipping the tape. Then try selling the tape at the destination (surely there is a decent market in SJC).

<comment><USER3> I would do the same, perhaps find some companies who does this and quote them.

<comment><AUTHOR> What companies do this?

</comment></comment></comment><comment><USER4> So I do agree with the rest of the comments that the absolute fastest way is to ship the disks and then copy the data. Now that being said if you can't or would rather not ship anything because of disks getting ruined, then the best thing to do is to find a high bandwidth internet connection and use something like IBM Aspera ([https://www-03.ibm.com/software/products/en/high-speed- file-...](https://www-03.ibm.com/software/products/en/high-speed-file- transfer))

Aspera is used widely in the Movie industry to move Tb size movies around (~2.5Tb). The key to Aspera is that it assumes that packet order doesn't matter so it will max out your pipes and it doesn't have to immediately report back about what packets were dropped and therefore is pretty efficient at getting the data across quickly.

</comment><comment><USER5> _Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway._ \-- Andrew S. Tanenbaum

<comment><USER6> This. Don't bother shipping the servers. Ship the disks. Copy them. Ship them back. Easy peasy.

</comment></comment><comment><USER7> Shipping storage servers is by far the fastest way. You can encrypt data if needed and have options to either fly the thing out or ship it ground.

</comment><comment><USER8> IBM just rolled out Snowball competitor[1], it has 10Gbps port, might be a good option.

[1]: [http://www.datacenterdynamics.com/content-tracks/servers- sto...](http://www.datacenterdynamics.com/content-tracks/servers-storage/ibm- rolls-out-cloud-courier-service-with-120tb-storage-blocks/98969.article)

</comment><comment><USER7> This sounds like a fun project.

</comment><comment><USER9> Option 1</comment>


Memory Management – Changes for the programmer over the years - <AUTHOR> https://uridiumauthor.blogspot.com/2018/06/memory-management.html <comment><USER2> The other way where managed memory is a problem is when it fails to deliver the performance of the usual memory allocator, forces "stop the world" events similar to mentioned defragmentation... And you're back to square one with the added complexity of having to work around the memory allocator in place. Java and its GC implementations come to mind.</comment>


IT Automation Using Infrastructure as Code - <AUTHOR> https://www.tasktop.com/blog/software-defined-it-automation-using-infrastructure-as-code/ <comment><AUTHOR> In this article I look at how Infrastructure as Code is used to manage IT operations in the application delivery lifecycle. Any thoughts?</comment>


Starting this summer, YC will be in California year-round - <AUTHOR> http://ycombinator.com/ycca.html <comment><USER2> Awesome news. Congratulations PG & JL!

</comment><comment><USER3> The gap between #1 (Silicon Valley) and #2 (Cambridge) just got bigger with this news.

<comment><USER4> I'm surprised it took this long. Boston area has been great for hardware startups, but the software scene is (IMO) a far distant 2nd to California. Have contemplated moving west a few times myself.

</comment></comment><comment><USER5> That's good really. The speaker lists always seem better for the California one, and the space is more conducive.

Out of curiosity, from what you can tell, has the economy affected the gap between the two locales at all? Did the already timid Boston investors just give up entirely? Or has it been pretty proportional?

<comment><AUTHOR> Hard to say, because the number of deals with Boston investors has always been so small as to be statistically insignificant.

Boston VCs may actually be _more_ interested in YC alumni lately, but I think that's because they only recently discovered YC.

With angels it's even harder to tell, because the Boston angel community is even weaker than the VCs. If I recall correctly, only one YC alum has been talking to a Boston angel lately, and he backed out of the deal in a pretty lame way. But with only one data point it's hard to say whether it's Boston, or the economy, or just that guy.

</comment></comment><comment><USER6> Boy did I see this one coming :)

I agree this move is better for the statups. I also agree that Palo Alto is better for kids than Cambridge. I think Arlington is slightly better than Palo Alto though.

And let me congratulate you again on the upcoming addition. Kids are great.

<comment><USER7> I agree with Arlington being slightly better than Palo Alto. In fact, you could say that I'm in the process of doubling down that particular gamble! Given that my brother's raising his kid in there and I'm here, I feel like I have a semi-informed opinion.

But I'm not sure that we'd have much luck convincing the expecting couple.

Congrats!

<comment><USER8> Arlington, VA? What makes that area particularly good?

<comment><USER9> _Arlington, VA?_

<http://news.ycombinator.com/item?id=444217>

 _Arlington, MA_ <http://en.wikipedia.org/wiki/Arlington,_Massachusetts>

</comment></comment></comment></comment><comment><USER10> And who is going to be pg's shadow while he's on paternity leave?

<comment><AUTHOR> I was planning to go with a five o'clock one. But Trevor can by now do a pretty good PG imitation, I believe.

</comment></comment><comment><USER11> Congratulations. I am curious. Why is Palo Alto a better place to raise kids? The weather? schools?

<comment><AUTHOR> Number 1, it's a small town-- embedded in suburbia that arrived later, but large parts of it are much as they were before. Cambridge is too urban. If you let your kid ride his bike in the street in front of your house, he'd last about 10 minutes. The other option in Boston is suburbs like Lexington and Concord, but though luxurious they have the usual suburban problems (not walkable, deadly dull).

Number 2, the weather.

<comment><USER7> re: Number 2

Does everyone get soft when they spend time out west? I've lost half my family to that coast and they all complain about the sort of weather that is optimal for sledding.

Doesn't anyone else miss having seasons?

<comment><USER12> I lived in Boston pretty much my whole life until September. It was 70 degrees here in Palo Alto yesterday. I was playing basketball outside in shorts and a tshirt. I don't miss the cold at all. Not even a bit. It's like a disease. I'm glad I got it cured.

<comment><USER13> My experience with Northern California is that it rains pretty well every day from December to March. Not that those few days when it doesn't aren't glorious, but people oversell the lack of winter. I think the best part of the climate is the fact that it's not insanely hot the rest of the year.

<comment><USER14> A raincloud must have followed you around! Even though that is the heart of the 'rainy season', in SF, about half those days have no measurable rain, and even those with rain are often just a few hundredths of an inch.

Here are historical records for downtown SF:

<http://ggweather.com/sf/daily.html>

(2005-2006 was especially rainy; was that when you set your 'norm'?)

<comment><USER13> As a matter of fact, it was. I did say "my experience." I arrived in SF in October 2005, left in Dec. 2007. Rainclouds seem to have been following me around forever.

<comment><USER15> Early 2006 was extremely wet. I remember getting caught in some crazy downpours. There were a number of floods down in Santa Cruz county that took out roads and caused mudslides. In The City, March 2006 was a record setting rainfall.

[http://www.sfgate.com/cgi- bin/article.cgi?f=/c/a/2006/03/31/...](http://www.sfgate.com/cgi- bin/article.cgi?f=/c/a/2006/03/31/WEATHER.TMP)

<comment><USER13> I still remember thinking - wow, they oversold me on the climate. And then it stopped raining at the end of March. For 8 months. Plus it seemed like the thermometer was pinned at 72 degrees every day.

<comment><USER16> > Plus it seemed like the thermometer was pinned at 72 degrees every day.

You say that like it's a bad thing.

<comment><USER13> Quite the opposite. As I said, I felt that I was oversold on the climate from my arrival in October till late March. Then, uh, wow.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Congrats on the soon-to-be newborn. But, I'm saddened by Boston being removed from the rotation.

</comment><comment><USER18> Boooooo.

Just kidding, but I was looking forward to you guys returning to Boston.

<comment><AUTHOR> Oh, we'll be back a lot. We love Cambridge. We're just not going to run YC there.

<comment><USER19> Keeping the office?

</comment></comment></comment><comment><USER20> Guess someone will just have to pick up the scraps in Boston.

<comment><USER21> That's an interesting thought. I would have never applied to YC if YC were always in Boston, so there must be someone out there who would never apply if it's always in California. Does that mean that, right now, a technically savvy angel out in Boston could start snatching up some of the MIT and Harvard alumni startups that YC ordinarily would have first dibs on? I dunno, but I guess if I were an investor in Boston, I'd be thinking about how to put myself in that position.

<comment><USER18> Being in California would have changed everything for us.

<comment><USER21> For the better or worse? (I know I've seen you identify your startup in the past, but I don't recall it right now, so I don't know whether you're doing well or have gone back to the drawing board.)

<comment><USER18> TicketStumbler.com. We're doing well:

<http://ticketstumbler.com/new-stuff/>

But if we had spawned in CA we would have required funding. So far, we've been able to get by without it.

To soon to tell if for better or worse :).

</comment></comment></comment></comment></comment><comment><USER22> Congrats! Good luck, have fun.

As someone who has happily chosen to raise her children in Cambridge, we all do what we think is best for our kids. Suburbia is _not_ for us; Huron Village is about as suburban as I can stand. :)

<comment><USER23> I'm in Huron village, and it's about as suburbia as I can stand. But, hey, to each his own.

Not to worry about Boston, there's actually an interesting announcement that will help fill the YC gap that is coming in the next 60 days.

</comment></comment><comment><USER24> Congrats on the kiddo, you guys! Mine is 6 months old already, and let me tell you: what a ride it's been!

Also looking forward to having the additional opportunity per year to apply to YC. :)

</comment><comment><USER25> Congratulations!

When we were expecting out first baby, everyone we met and talked to advised us to get as much sleep as possible, because it will be a bit difficult to get a good night sleep for the first few weeks/months after the baby arrives. I won't advise that to you guys, because I couldn't really understand how sleeping longer for a few weeks/months now will help you sleep less for a few weeks/months later on.

</comment><comment><USER26> Augh no! I'm determined to graduate, dammit, and now you've gone and made summer with YC even more attractive. Good move, PG & co.

</comment><comment><USER27> Congratulations to you both!

We're applying this summer, and while we're on the East Coast we were wondering whether Boston's not being a start-up town was good or not. Guess now we don't have to worry about that.

Edit: any info on when exactly the application round opens?

</comment><comment><USER28> So What ever happened to Paul's article that Cambridge is a hot spot for start ups? I guess this means that there is a spot for someone else to take yc's spot in the Boston area. Anyone know of replacements?

</comment><comment><USER29> Awesome, good to have you guys here permanently, and congrats in advance!

</comment><comment><USER30> Wow, congratulations on the baby. Ours has been a huge change in our lives, but is really a source of joy (and worry:-) Any ideas about a name, or will it only be revealed at the last moment?

</comment><comment><USER31> Congrats. How soon are you gonna teach your kid programming?

</comment><comment><USER32> Congratulations.

Northern California probably has a stronger network of homeschoolers than greater Boston as well, although both places are all right in that regard.

</comment><comment><USER33> We were predicting this after we interviewed with them in November. :) Congrats, pg and Jessica.

</comment><comment><USER34> congrats to both of you, really exciting news. love that the reasons all make sense but really it was all about where you want to live and raise kids. despite it all this seems like the best way to make decisions: "whats best for us?"

</comment><comment><USER35> Wonderful news. Congratulations!

</comment><comment><USER36> Congratulations!

The first of many kids hopefully (assuming you want many kids, that is).

</comment><comment><USER37> Congrats PG & JL!

</comment><comment><USER38> Congratulations on the new baby!

</comment><comment><USER39> Congratulations!

</comment><comment><USER40> Congratulations.

</comment><comment><USER41> congrats PG. looking forward to applying.

</comment><comment><USER42> congrats. happy for you both!

</comment><comment><USER43> 'grats!!

</comment><comment><USER44> w00t!</comment>


Jed Shaw claims revoking GPL is possible, demands fork relicense as BSD - <AUTHOR> https://github.com/moggers87/salmon/issues/8

<comment><USER2> The headline says "demands fork relicense as BSD" (Murphy's law guarantees that HN mods will change it), but Lamson's new license ( [https://github.com/zedshaw/lamson/blob/master/LICENSE](https://github.com/zedshaw/lamson/blob/master/LICENSE) ) is not BSD. It has some creative clauses: "4\. Contributors agree that any contributions are owned by the copyright holder and that contributors have absolutely no rights to their contributions. 5. The copyright holder reserves the right to revoke this license on anyone who uses this copyrighted work at any time for any reason."

</comment><comment><USER3> In every case where a non-lawyer has a contradicting legal opinion as to those of the legal profession (ie, actually lawyers), one should be a bit careful before acting. Zed Shaw is a non-lawyer who thinks that a license which itself is says is non-revokable, is revokable. Several certified lawyers strongly disagree with Zeds opinion.

The best action to do is to follow the style of Wikipedia in cases like this. Do exactly _nothing_. do not reply, do not engage or act in any way different from before. Simply just call a lawyer (or fsf, or eff, or sflc), and let those whoes job it is to deal with legal threat, deal with the legal threat.

</comment><comment><USER4> That is _Zed_ (not Jed) Shaw.

And the idea that a gratuitous license is revocable by notice alone at any time is decidedly _not new_ (its fairly well established law.)

The _effect_ of that revocation on the position of the licensor vis-a-vis those who had relied upon the license prior to the revocation, given the doctrine of promissory estoppel, is a little more complicated.</comment>


What startup ideas might work if gas was $0.06 per gallon? - <AUTHOR>

Just throwing this out for discussion. It's not an entirely theoretical question. Assuming you could operate within the Venezuelan regime, that is. You might be able to pull this off if you stay small enough not to be noticed and nationalized.<p>Source: http://www.bloomberg.com/slideshow/2013-02-13/highest-cheapest-gas-prices-by-country.html#slide61 <comment><USER2> I'd give it away as an incentive.

Imagine you went a restaurant where as you ate, the valet not only parked your car, but filled it with ... for free. A 15 gallon fill-up would only cost 90¢, plus valet time. Bring on the carne mechada.

That, or something to do with cheap explosions.

<comment><USER3> But if gas was widely available at 90c per tank, it wouldn't be a big deal. People don't flock to restaurants now because they give free tap water.

<comment><USER2> True, but there'd be a window where it was nice perk.

The first businesses to offer "free wifi!" or unlimited miles on a rental car had a first-mover advantage.

</comment></comment></comment><comment><USER4> I would do my first startup in the airline industry :).

</comment><comment><USER5> Anything that has any connection with transporting anything. That goes for all of the businesses that I can think of.

</comment><comment><USER6> If you have to grossly limit your revenue to stay unnoticed by a hostile government then why bother?

<comment><AUTHOR> Keeping your revenue below $250m or so might be enough. Happened to HSBC and Chevron as I recall. I hardly consider that as a gross limitation given what most people on this site will realistically achieve.

</comment></comment><comment><USER7> What about the obvious one. Buy gas at 6 cents and sell it on the black market.

<comment><AUTHOR> This is actually done:

[http://latimesblogs.latimes.com/laplaza/2008/07/venezuelans-...](http://latimesblogs.latimes.com/laplaza/2008/07/venezuelans- cro.html)</comment></comment>