19 ms·

The Longflow Manifesto

204 points by pkolaczk 10y ago

ThomPete 10y ago
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 10y ago
  >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 10y ago
    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 10y ago
      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.
tjstankus 10y ago
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?
vinceguidry 10y ago
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.
wojcech 10y ago
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 10y ago
  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 10y ago
    > 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
bryanrasmussen 10y ago
I distrust any engineer who writes quality is infinitely superior to quantity.
- webmaven 10y ago
  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 10y ago
    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.
    - edblarney 10y ago
      This is true in general. But I think there are some things that we should be 'thoughful' about. APIs, and platforms come to mind. Typescript is amazing. It's evolved, and they've 'added on' - but if they had to do fundamental re-works ... it would not be good :). Also ... security ... anything dealing with money ... the risk equation is different, and it just helps to be thoughtful. For an enterprise problem that is not super-complex, and fairly straight forward, but which involves money or legal issues ... a slow and classical Eng approach might be optimal.
    - rabidrat 10y ago
dchuk 10y ago
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.
AbrahamParangi 10y ago
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.
- dozzie 10y ago
  It's really sad if you don't strive to excel at your craft. Though I understand that most of the craftsmen don't care about their work, they care about bringing home a good living.
  - tyingq 10y ago
    It may not be the posters desire to excel...just the reality of what's possible in their current job. I suppose their are job choices you can make the open up more possibilities, but that brings other factors into play, not all of which are easy choices (salary, where to live, career stability, etc).
    - pdimitar 10y ago
      > just the reality of what's possible in their current job. Reality is maleable, albeit it's not an easy thing to do, that's a fact. The real question is if you are willing to change your reality -- or are you a coffee-addicted slouch who is always too tired to try and change anything and just wants to go home for a proper sleep after yet another soul-draining workday. Apologies for being a bit extreme. IMO it helps illustrate my point a little better. No offense is meant to you or anyone else reading this.
      - tyingq 10y ago
        No offense taken. I've been where that poster has been though. "If you are willing to change your reality" isn't always as easy as it sounds. I could have easily escaped, for example, if I moved away to a different city. But, I didn't want to uproot my children. I did eventually escape, but there really wasn't a safe way to do so quickly.
rolfvandekrol 10y ago
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 10y ago
  > 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 10y ago
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 10y ago
  > 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 10y ago
    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 10y ago
      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 10y ago
        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?
        10y ago
thisisrobv 10y ago
> 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.
calinet6 10y ago
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 10y ago
  > 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 10y ago
jryan49 10y ago
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 10y ago
  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.
solidsnack9000 10y ago
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?
exratione 10y ago
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.
tony-allan 10y ago
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?
cwyers 10y ago
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.
edblarney 10y ago
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.
GavinMcG 10y ago
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.
peteretep 10y ago
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 10y ago
  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.
  - Tharkun 10y ago
    Most devs have never seen a healthy project, period. Regardless of methodology. Why would this longflow garbage be any different?
- Tharkun 10y ago
  Couldn't agree more. I stopped reading the "manifesto" after the "bullshit" statement.
- jon-wood 10y ago
  I'm a big fan of agile, but I fundamentally disagree with some of the things you're suggesting. Developers aren't actually special snowflakes who must be defended from the realities of the wider business, and they sure as hell shouldn't be hiding away work they'd like to do in what are nominally feature cards, what you're describing sounds more like the US legislation process of slipping funding for a coal power plant into a law which is designed to prevent discrimination so that the right person will vote for it. Trust is earned, and intentionally deceiving the product owner as to what they're going to get goes against that. A properly run and supported development team should be able to go to their product owner and make a convincing argument as to why they should be doing some work on paying down technical debt. If they can't convince the product owner in terms that are understood and taken on board that's a failing of the development team and the process they're working within. Or maybe the interest on that debt just doesn't outweigh the features that are being prioritised over it. In an ideal situation developers will be involved enough in the rest of the business to be able to see that without even bothering with pitching low value tasks as a priority. Equally my experience is that points based estimates don't really help anyone. The product owner is inevitably going to report to their management in terms that are more widely understood, namely time, and to do so they'll convert points into time. If you're lucky they'll use the current average rate of points/sprint to do that, if you're unlucky they'll just say 1 point = 1 hour and leave it at that. By extension that doesn't help the development team either, because they're doing estimates in points on the understanding that they don't directly map to time, and then get grief later when the points didn't directly map to time. Maybe I've just never seen Scrum done really well, and with sufficient buy in these aren't actually major issues, but my experience tells me no one is helped by adding a new language solely used for communicating the development team's plans and progress.
dahart 10y ago
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.
- lupin_sansei 10y ago
  Exactly. Pushing these ideas too hard gets your labeled as a troublemaker and uncooperative. I've learned to choose my battles very carefully.
- bjourne 10y ago
  > Engineers who refuse to make & meet deadlines, refuse to communicate & report status regularly, and work on problems of their own choosing But that is a straw man. No one is suggesting anything of the above is good behaviour.
  - dahart 10y ago
    Are you sure? I was responding to: "Estimates are to be avoided at all cost." "Don't fear running late." "Having a meeting once in a week/month or other indicator based solely on time is meaningless." "Value quality over deadlines."
SatvikBeri 10y ago
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.
peterbonney 10y ago
"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 10y ago
  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 10y ago
    "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.
- pdimitar 10y ago
  Thank you for your perspective and a diplomatic peaceful language. You're a good manager. =) One thing I disagree on however: > Besides: managers are optimists, and in the absence of information to the contrary we will assume everything is easy. :) To me, that's a tongue-in-cheek internal joke that's simply not translating well to reality. Most of the times managers come off as total pessimists to me, in terms of always assuming you're over-allocating hours because you want to lie on your ass, or work on your side projects in your paid workday, or simply because you're a crappy programmer. They are under the illusion that pressure = productivity. Most of the time it seemed like the managers don't trust programmers and try to micro-manage them. I know you'll say this means they're bad managers but the fact that statistically they are most likely the majority isn't exactly helping as well, no?
bluetwo 10y ago
Seems like it is optimizing a workflow to maximize the happiness of the developer, perhaps at the sacrifice of other things.
- pdimitar 10y ago
  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.
mathattack 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.
daine 10y ago
Re-read the Agile Manifesto from time to time. It takes under thirty seconds. http://agilemanifesto.org http://agilemanifesto.org
seanwilson 10y ago
> 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 10y ago
  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.
  - alfonsodev 10y ago
    The problem is that as you said it takes a 'serious effort', and yet you think you were "lucky"(perhaps experienced, intuitive, mature, knowledgable enough), but other teams that aren't so "lucky" make the same effort without the results and get frustrated, because is frustrating to be late all the time. So I can understand that some people just want to drop estimations, but I don't agree. I wrote a comment below on why still we need estimations and how I think the risk and frustration could be reduced.
alfonsodev 10y ago
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 10y ago
  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.
  - alfonsodev 10y ago
    Sure you can, but do they always deliver on time ? There are may cases that come to my mind like the new Berlin airport or Panama canal's expansion.
RyanZAG 10y ago
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 10y ago
  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.
- deleted 10y ago
  [deleted]
kluck 10y ago
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.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
daryl_antony 10y ago
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 10y ago
  Diplomatically, and accurately, put. I say this as a dev and business owner.
partycoder 10y ago
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 10y ago
  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.
abalone 10y ago
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 10y ago
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.
kriro 10y ago
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 10y ago
  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.
fagnerbrack 10y ago
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.md#a-typical-implementation https://github.com/Nax/longflow-manifesto/blob/master/README... [2]: https://en.wikipedia.org/wiki/Argument_from_authority https://en.wikipedia.org/wiki/Argument_from_authority
bitwize 10y ago
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.
drderidder 10y ago
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/
dosethree 10y ago
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.
ycspring 10y ago
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.

204 points by pkolaczk 10y ago

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 10y ago
>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 10y ago
  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 10y ago
    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.

tjstankus 10y ago

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?

vinceguidry 10y ago

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.

wojcech 10y ago

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 10y ago
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 10y ago
  > 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

bryanrasmussen 10y ago

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

webmaven 10y ago
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 10y ago
  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.
  - edblarney 10y ago
    This is true in general. But I think there are some things that we should be 'thoughful' about. APIs, and platforms come to mind. Typescript is amazing. It's evolved, and they've 'added on' - but if they had to do fundamental re-works ... it would not be good :). Also ... security ... anything dealing with money ... the risk equation is different, and it just helps to be thoughtful. For an enterprise problem that is not super-complex, and fairly straight forward, but which involves money or legal issues ... a slow and classical Eng approach might be optimal.
  - rabidrat 10y ago

dchuk 10y ago

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.

AbrahamParangi 10y ago

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.

dozzie 10y ago
It's really sad if you don't strive to excel at your craft. Though I understand that most of the craftsmen don't care about their work, they care about bringing home a good living.
- tyingq 10y ago
  It may not be the posters desire to excel...just the reality of what's possible in their current job. I suppose their are job choices you can make the open up more possibilities, but that brings other factors into play, not all of which are easy choices (salary, where to live, career stability, etc).
  - pdimitar 10y ago
    > just the reality of what's possible in their current job. Reality is maleable, albeit it's not an easy thing to do, that's a fact. The real question is if you are willing to change your reality -- or are you a coffee-addicted slouch who is always too tired to try and change anything and just wants to go home for a proper sleep after yet another soul-draining workday. Apologies for being a bit extreme. IMO it helps illustrate my point a little better. No offense is meant to you or anyone else reading this.
    - tyingq 10y ago
      No offense taken. I've been where that poster has been though. "If you are willing to change your reality" isn't always as easy as it sounds. I could have easily escaped, for example, if I moved away to a different city. But, I didn't want to uproot my children. I did eventually escape, but there really wasn't a safe way to do so quickly.

rolfvandekrol 10y ago

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 10y ago
> 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 10y ago

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 10y ago
> 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 10y ago
  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 10y ago
    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 10y ago
      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?
      - 10y ago

thisisrobv 10y ago

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

calinet6 10y ago

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 10y ago
> 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 10y ago

jryan49 10y ago

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 10y ago
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.

solidsnack9000 10y ago

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?

exratione 10y ago

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.

tony-allan 10y ago

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?

cwyers 10y ago

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.

edblarney 10y ago

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.

GavinMcG 10y ago

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.

peteretep 10y ago

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 10y ago
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.
- Tharkun 10y ago
  Most devs have never seen a healthy project, period. Regardless of methodology. Why would this longflow garbage be any different?
Tharkun 10y ago
Couldn't agree more. I stopped reading the "manifesto" after the "bullshit" statement.
jon-wood 10y ago
I'm a big fan of agile, but I fundamentally disagree with some of the things you're suggesting. Developers aren't actually special snowflakes who must be defended from the realities of the wider business, and they sure as hell shouldn't be hiding away work they'd like to do in what are nominally feature cards, what you're describing sounds more like the US legislation process of slipping funding for a coal power plant into a law which is designed to prevent discrimination so that the right person will vote for it. Trust is earned, and intentionally deceiving the product owner as to what they're going to get goes against that. A properly run and supported development team should be able to go to their product owner and make a convincing argument as to why they should be doing some work on paying down technical debt. If they can't convince the product owner in terms that are understood and taken on board that's a failing of the development team and the process they're working within. Or maybe the interest on that debt just doesn't outweigh the features that are being prioritised over it. In an ideal situation developers will be involved enough in the rest of the business to be able to see that without even bothering with pitching low value tasks as a priority. Equally my experience is that points based estimates don't really help anyone. The product owner is inevitably going to report to their management in terms that are more widely understood, namely time, and to do so they'll convert points into time. If you're lucky they'll use the current average rate of points/sprint to do that, if you're unlucky they'll just say 1 point = 1 hour and leave it at that. By extension that doesn't help the development team either, because they're doing estimates in points on the understanding that they don't directly map to time, and then get grief later when the points didn't directly map to time. Maybe I've just never seen Scrum done really well, and with sufficient buy in these aren't actually major issues, but my experience tells me no one is helped by adding a new language solely used for communicating the development team's plans and progress.

dahart 10y ago

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.

lupin_sansei 10y ago
Exactly. Pushing these ideas too hard gets your labeled as a troublemaker and uncooperative. I've learned to choose my battles very carefully.
bjourne 10y ago
> Engineers who refuse to make & meet deadlines, refuse to communicate & report status regularly, and work on problems of their own choosing But that is a straw man. No one is suggesting anything of the above is good behaviour.
- dahart 10y ago
  Are you sure? I was responding to: "Estimates are to be avoided at all cost." "Don't fear running late." "Having a meeting once in a week/month or other indicator based solely on time is meaningless." "Value quality over deadlines."

SatvikBeri 10y ago

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.

peterbonney 10y ago

"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 10y ago
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 10y ago
  "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.
pdimitar 10y ago
Thank you for your perspective and a diplomatic peaceful language. You're a good manager. =) One thing I disagree on however: > Besides: managers are optimists, and in the absence of information to the contrary we will assume everything is easy. :) To me, that's a tongue-in-cheek internal joke that's simply not translating well to reality. Most of the times managers come off as total pessimists to me, in terms of always assuming you're over-allocating hours because you want to lie on your ass, or work on your side projects in your paid workday, or simply because you're a crappy programmer. They are under the illusion that pressure = productivity. Most of the time it seemed like the managers don't trust programmers and try to micro-manage them. I know you'll say this means they're bad managers but the fact that statistically they are most likely the majority isn't exactly helping as well, no?

bluetwo 10y ago

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

pdimitar 10y ago
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.

mathattack 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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.

daine 10y ago

Re-read the Agile Manifesto from time to time. It takes under thirty seconds. http://agilemanifesto.org http://agilemanifesto.org

seanwilson 10y ago

> 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 10y ago
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.
- alfonsodev 10y ago
  The problem is that as you said it takes a 'serious effort', and yet you think you were "lucky"(perhaps experienced, intuitive, mature, knowledgable enough), but other teams that aren't so "lucky" make the same effort without the results and get frustrated, because is frustrating to be late all the time. So I can understand that some people just want to drop estimations, but I don't agree. I wrote a comment below on why still we need estimations and how I think the risk and frustration could be reduced.

alfonsodev 10y ago

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 10y ago
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.
- alfonsodev 10y ago
  Sure you can, but do they always deliver on time ? There are may cases that come to my mind like the new Berlin airport or Panama canal's expansion.

RyanZAG 10y ago

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 10y ago
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.
deleted 10y ago
[deleted]

kluck 10y ago

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.

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

daryl_antony 10y ago

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 10y ago
Diplomatically, and accurately, put. I say this as a dev and business owner.

partycoder 10y ago

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 10y ago
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.

abalone 10y ago

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 10y ago

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.

kriro 10y ago

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 10y ago
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.

fagnerbrack 10y ago

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.md#a-typical-implementation https://github.com/Nax/longflow-manifesto/blob/master/README... [2]: https://en.wikipedia.org/wiki/Argument_from_authority https://en.wikipedia.org/wiki/Argument_from_authority

bitwize 10y ago

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.

drderidder 10y ago

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/

dosethree 10y ago

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.

ycspring 10y ago

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.