
The Longflow Manifesto - pkolaczk
https://github.com/Nax/longflow-manifesto/blob/master/README.md
======
dahart
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.

~~~
imagist
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.

~~~
dahart
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?

~~~
imagist
> 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.

~~~
dahart
> 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.

~~~
imagist
> 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?

------
calinet6
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)

~~~
mistermann
> 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.

~~~
calinet6
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.

~~~
mistermann
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.

------
AbrahamParangi
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.

~~~
parenthephobia
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._

~~~
tootie
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.

~~~
flukus
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.

~~~
couchand
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.

------
peteretep
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.

~~~
couchand
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.

------
seanwilson
> 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.

~~~
SatvikBeri
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.

~~~
seanwilson
> 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.

~~~
pdimitar
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.

------
rolfvandekrol
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.

~~~
dozzie
> 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.).

------
mwcampbell
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."

~~~
parenthephobia
> _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.

~~~
mwcampbell
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.

~~~
dudul
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.

~~~
mwcampbell
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?

~~~
pkolaczk
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.

------
SatvikBeri
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.

------
jryan49
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.

~~~
pdimitar
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.

------
ThomPete
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.

~~~
tyingq
>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)?

~~~
ThomPete
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.

~~~
tyingq
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.

------
dchuk
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.

------
drderidder
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/)

------
kriro
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.

~~~
discordianfish
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.

------
peterbonney
"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. :)

~~~
sheepmullet
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.

~~~
peterbonney
"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.

------
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?

------
vinceguidry
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.

------
daryl_antony
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.

~~~
tomcam
Diplomatically, and accurately, put. I say this as a dev and business owner.

------
tjstankus
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?

------
cwyers
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.

------
fagnerbrack
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)

------
solidsnack9000
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?

------
partycoder
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.

~~~
pdimitar
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.

------
bryanrasmussen
I distrust any engineer who writes quality is infinitely superior to quantity.

~~~
webmaven
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.

~~~
cookiecaper
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.

~~~
rabidrat
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?

~~~
cookiecaper
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.

------
kluck
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.

------
daine
Re-read the Agile Manifesto from time to time. It takes under thirty seconds.

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

------
RyanZAG
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.

~~~
pdimitar
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.

------
exratione
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.

------
ycspring
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.

------
bitwize
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.

------
alfonsodev
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.

~~~
mfukar
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.

~~~
pdimitar
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.

~~~
mfukar
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. :-)

~~~
pdimitar
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.

~~~
mfukar
Totally agree, and it's useful. We need people to challenge established
assumptions from time to time.

------
wojcech
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)

~~~
dchuk
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.

~~~
wojcech
> 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

------
GavinMcG
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.

------
mathattack
_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.

~~~
pdimitar
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.

~~~
mathattack
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.

~~~
pdimitar
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.

~~~
mathattack
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.

------
abalone
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.

------
dredmorbius
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.

------
dosethree
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.

------
bluetwo
Seems like it is optimizing a workflow to maximize the happiness of the
developer, perhaps at the sacrifice of other things.

~~~
pdimitar
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.

------
thisisrobv
> 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.

------
edblarney
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.

