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.

I find biweekly or monthly meetings with stakeholders to be extremely useful. I do not tie my work output to these meetings. They are just status updates, feedback, and plans for the future. I try to walk into them without a plan, just a set time for a conversation. Sometimes I don't have anything to show unless they "want to watch tests run." In which case I get a resounding, "No," and we move on. It is up to you as a developer to set the tone for these meetings. Frame it as a conversation, not a presentation.

Most process breakdowns and anger are rooted in the fact that people don't understand each other's job. Sitting in an office, and passing "quality" work under the door irregularly does not help. Management has no visibility into this and will eventually lead to confrontation. Being open and honest with communication builds trust which will lead to longer lasting happiness than sequestering yourself away.

I would agree that software estimates are hard. The simple solution to that is take whatever you think it will be and double it, triple it, quintuple it. Whatever works for you. Under promise and over deliver might be controversial, but I think it applies here. It's more about giving yourself room than wowing management.

Sometimes those misestimations are because you are blocked by other team. No one develops by themselves, no matter how much of a 10x engineer you think you are. This is where the trust you built with management comes into play. Use them as a tool to get things done across teams.

This manifesto is all about giving back the power to the developer to manage their own time. It basically says, "Developers do want you want. And management, stay out of their way." Its reactionary, because the author feels like Agile/SCRUM has been used against them. This is completely understandable. Feeling powerless is heartbreaking. But trying to implement something like this would never fly. And if it did, it would eventually be twisted just like Agile has. No manifesto will help you in this case. You need to learn how to communicate, and through communication reassert your power over your situation and the decisions being made by participating.

This is such an important thing to note. Almost everyone claims to be using an "agile development process" these days. I'm certain at least 75% of the people that claim to do this don't know there's an actual real process attached to that claim and instead just think it's a way to tell people they're a cool company to work at.

The bosses are going to have their way. If they want a meeting, your "agile manifesto" is not going to block them, regardless of the promises made in their circulations and recruitment material. Some are more subtle about this fact than others.

Regular communication is critical. Often developers forget that the reason this communication is heavily structured, and often in a less than optimal way, is because of the way managers are expected to operate.

For example I have standard weekly meetings because they allow me to block out that time slot. Sure it might be more useful to meet with you tomorrow instead but if I don't have standard times I will be swamped myself

As an engineer you must understand that they are paying you for solutions.

Said that, as an engineer you can and must plan for this and embrace it. You must design your software with enough flexibility to support continuous changes on your systems. You must also design your process.

And if your are tech leading, you have this additional responsabilities:

* Maintain a slow flow of changes (for core, architecture, ...)

* Maintain a fast flow of changes (for business)

With those on place perhaps you can give a not so frantic pace on the important places of your system (your engineers will thank you and will love working in these). And business will appreciate that you don't fight every proposed change. (fighting them is uphill and generally useless)

And there are those you can barely keep your eye open because the things communicated are obvious, redundant or irrelevant.

I think it's still critical to demonstrate incremental value, but there's a deadline oriented culture at some places that just ends up hurting the business by causing people to make the wrong trade offs and short term thinking. Not so bad in some contexts, but terrible in others.

Very true. And memories are faulty. And planning meetings can be inconsistant.

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

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

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

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

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

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

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

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

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

The bottom line is part of the definition.

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

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

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

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

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

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

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

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

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

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

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

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

This is all true.

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

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

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

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

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

Okay, yes, I agree with that completely!

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

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

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

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

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

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

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

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

What do these contribute to high quality software?

Removing the bottom line from consideration doesn't guarantee a good result, obviously. But that doesn't mean that bottom lines can't decrease quality.

But that is a straw man. No one is suggesting anything of the above is good behaviour.

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

But, unless management wants to get rid of estimates and deadlines, it is advocating an antagonistic belief system. It is insubordinate and will cause people to act insubordinately merely to believe that estimates should be avoided at all cost, and that contact between engineers and managers should be minimized and not done on a regularly scheduled basis.

Managers can't do their jobs if engineers believe those things. Programmers can't either, some of them just don't know it yet. You can't succeed as an engineer if you can't produce work on a deadline, and estimate and budget your time to meet the company schedule.

Accepting that, and understanding why estimates and deadlines and scheduled communication are important to your manager and to the company, and learning how to better facilitate and participate in those activities will make you a better, more valuable engineer.

I agree that 'at all cost' doesn't seem reasonable. Yet I think they should try very hard to avoid them. Estimates, meeting and deadlines might be required some time. You might had to announce a release date for some new features. That's a deadline you can't always avoid. But you can avoid arbitrary deadlines that are just there to 'motivate' engineers and get them to ship "something". That leads to worse quality and technical debt decreasing overall productivity on the long term.

I have a feeling that whoever wrote that manifest prefers if it is read literally. ;) I guess that is the heart of the issue, isn't it? The author thinks it would be better if companies adapted to how engineers prefer to work over engineers adapting to how companies prefer to work.

For example, if I estimated a task to be 2w and management confirmed that, then after two weeks management will start to be angry at me if I will report that task will need 3x time to finish. 3x error is not uncommon for estimates.

If I will avoid estimates, then manager will talk something like "try this task for 3 days and if it will require more than 3w to finish, then skip it, because we will not meet the deadline", which is better way to communicate.

There's a fine line between a manager being understandably frustrated with poor estimates, and a manager being less understandably frustrated they can't pressure you into crunch - but I do draw that line. I find the former completely understandable, the latter completely unreasonable.

There's a similarly fine line between a manager trying to gauge the scope of tasks and help identify unnecessary dead weight that can be cut or delayed, and a manager trying to simply negotiate the estimate down, without cutting anything. The former is reasonable and at times valuable, the latter is either trying to bend the truth to keep their stakeholders 'happy' or pressure games to entice crunch - completely unreasonable - or outright denial (frankly, a failure to do their job right.)

Unfortunately, I think the unreasonable folk ruin it for the reasonable folk, to some degree. Even with managers in the former camp, and with devs I'm convinced recognize their managers as being in the former camp, simply trying to even go through the motions of estimating seem to add a lot of stress and heartache.

Good signs: They point out stuff that's vague, try and actually try to eliminate some of the blind guesswork, helping to produce reasonable estimates, and try to compensate for your bad estimates while guiding you towards making better ones.

Bad signs: They complain about work taking too long, or adjust your estimates down behind your back.

Thank you, thank you, THANK YOU! Why isn't this taught in the MBA courses? Why isn't this common sense?

As for the rest of your comment, my personal observations have followed Occam's Razor effect -- it's not that people are in denial or are blind or they can't serve the business well per se; they're simply vengeful immature people put in positions of power. They want to RULE and they hate the idea that their subordinates can dictate the pace and the format of the work, and they want "to get back at the nerds" <-- and this is actual overheard conversation between two managers in one of my former jobs.

Being a manager requires a lot of emotional intelligence. Most of them don't have it and never will. That's one of the core problems with who to put in a position of power.

Apologies for going on a tangent and generalizing a bit. But these views of mine are intertwined with the OP (and your comment of it).

Hey, you're welcome ;).

People are weird. Confusing. Illogical. Communication is hard, management is hard, and emotional intelligence is perhaps not as high up on people's bucket lists of virtues to aspire to as one might hope.

Personally, it wasn't until I got to see the difference between extremes of good vs bad management first hand, and in depth (for me, this was heavy involvement in several project's schedules), that I was able to really pick apart the differences between the two, and pick up on the relatively subtle differences in surface level behavior, and trace that all the way back to the more fundamentally different modes of operation.

> They want to RULE and they hate the idea that their subordinates can dictate the pace and the format of the work, and they want "to get back at the nerds" <-- and this is actual overheard conversation between two managers in one of my former jobs.

Ooof, my sympathies. I'd hope they were being sarcastic, but that's perhaps more the power of denial than anything else.

I've seen a borderline case or two. I've also seen plenty of people between a rock and a hard place, and a few layoffs from the resulting collisions.

That was when I was 27-28. Working in that place was a VERY educational phase of my life. It was probably the first time ever for me when I decided I don't want to "fight" and give arguments and counter-arguments (which I actually did a few weeks before that but I quickly gave up). I was finally able to make the correct conclusion that people by default don't want to change their views and that I should simply switch jobs, which I did.

For what it's worth, I'd be happy to work with a person like yourself. You strike me as very well-connected to human nature reality. Kudos for that.

I think many people's aversion to estimates comes from a culture like the one you're describing in your first option, one where developers are asked for estimates but they're taken as hard commitments. The solution to that sort of culture is exactly the opposite of the one being proposed in this manifesto - instead of siloing ourselves away further and avoiding contact, we should communicate more. (Good) managers don't get angry at a 2 week task taking 6 weeks, they get angry at finding out that the 2 week task will take 6 weeks only after we hit the point at which they were expecting everything to be done. With a little intuition we can tell that a task is going to miss its deadline long before that deadline hits - presumably we've broken things down into smaller sub-tasks, if we haven't completed 25% of those when you're about 25% of the way in, we're going to miss our deadline. The typical developer has a tendency to convince themselves they'll catch up later on, I certainly do, but in all likelihood we won't. That 25% point is the time to sit down with the manager and talk things over. Bring options, make it clear that if the deadline matters that much some features might have to be dropped, or released later. Or maybe the deadline doesn't matter, but they'll need to rearrange things so that another person is working on a feature which has a deadline 6 weeks out.

I get how appealing the proposal to just do away with deadlines, meetings, and regular updates can be, but that's only practical in an organisation entirely staffed by developers without any outside influences. Those influences will include all sorts of things, from investors to the season (woe betide the retailer who didn't bother estimating how long functionality to handle Christmas orders was going to take and released it on the 26th of December because that's when it was done). In the real world you're not building features in isolation so we need a way to communicate to others what they should expect, and when they should expect it.

It doesn't matter how many times you tell management it's just an estimate and should be treated flexibly; if you estimate that a feature will be done in about two weeks, come two weeks and one day you WILL be called out onto the carpet if it's missing or incomplete.

But it's a problem we're stuck with, it cannot be manifestoed away. The contract that follows an estimate is an unavoidable problem because the business has a time & money budget it has to fit into. This is a universal problem that all people have - how to get the most of what we want given limited resources. How do I decide which side project to start with an hour a night after the kids go to bed? How do you tell someone else you can do something -- anything moderately complicated -- without estimating how long it'll take? How can I make sure I die happy? How do you get someone's business without making promises that you can deliver a reasonable product in a reasonable amount of time? How can you write code for an employer without thinking about how long it will take? Why should an employer even employ you if you don't believe in the value of budgeting, and instead prefer to build "the highest quality" for unspecified and unlimited amounts of time?

It's a balancing act, and it's painful to be expected to estimate work and then somehow meet those inaccurate estimates. But managers are in the exact same position, it is important to understand why they're asking for estimates -- because they need them. Is it better to improve, to learn how to estimate better, and how to communicate better, or is it better to avoid conversations about the budget and have a never ending fight with the organization's attempts to manage it's expenditures?

I've tried fighting that fight, because I too used to be naive. I now understand why estimates are good for the company, and I understand why they're good for me as an engineer. In my experience, the more fruitful avenue is to give managers what they need and help them do their jobs. You will earn allies that can help you defend your schedule when it goes long, you will earn trust by the company and become respected as an engineer who can do what he says he can do. Once you have that trust, spotting errors in your own estimates are likely to be believed and even valued.

Sounds derogatory to the person you're arguing with. Is that your intention?

> I now understand why estimates are good for the company, and I understand why they're good for me as an engineer.

I realize this might be a wrong interpretation from my side but you do sound like you were dragged in a meeting, and the mystical they "explained how the real world works" to you, and then you took their side. A bit extreme interpretation I admit but IMO you should've chosen milder language if that interpretation isn't your intention.

Look, I too think this "manifesto" is worded stronger than it should have been, and that it's a bit extreme. Nobody can realistically expect that the people paying salary to you will just leave you the hell alone and wait for you to contact them to announce stuff. That's not gonna happen. But the way you word your responses here makes me think you're more of a business person now and not an engineer.

On the building trust point however you're 100% spot on. I've found that to be an extremely precise description -- be upfront, try to serve the business needs as best as you can, make honest effort to make yourself a predictably producing asset and when sh*t hits the fan the people you work for will give you the benefit of the doubt.

I think the disconnect between managers and programmers always stems from if we should look at the programmers as assembly line workers or craftsmen. The difference between how you treat either is pretty obvious however, so I won't go there.

No, I was referring to the manifesto, and circling back around to my initial comment on the manifesto. Moreover I did intend for this to be self-deprecating, as I said, I have gotten this wrong in the past and been naive in the same way that I critiqued the manifesto for being naive. I am sharing lessons I've learned the hard way.

> IMO you should've chosen milder language

I'm honestly surprised, saying "I understand" is pretty friggin' mild language... I don't see clearly what your interpretation is or why you're finding it offensive (it sounds like you're finding it offensive?), feel free to clarify.

> you do sound like you were dragged in a meeting, and the mystical they "explained how the real world works" to you, and then you took their side

Well, I am summarizing here. We all are. I can't share the subtleties or make this soft without writing my life story. I do try to extend benefit of the doubt in forum discussions, and I hope to receive the same. I try to assume that people understand there are always corner cases and subtleties we don't have the time to explain.

> But the way you word your responses here makes me think you're more of a business person now and not an engineer.

Is that somehow bad? I have been an engineer in the past, I have been an engineering manager leading teams inside large businesses, and now I am a (startup) business owner and engineer at the same time. I believe my experience doing both gives me a unique perspective that many engineers who have no business experience lack, and I'm sharing that perspective here. I happened to have come to the conclusions I've written down here while engineering, before I ever became a manager or business owner, but I think my management and business experience only makes my case stronger, not weaker.

The manifesto reads as if it was written by an engineer who has no business perspective, and my issue with it is not that it was strongly worded, it is that the goal is misguided. I believe, based on my experience as an engineer and a business person that avoiding timely communication and avoiding budget discussions in the name of a personal definition of "quality" are bad goals that rarely result in actual high quality software that actually helps the business. Moreover, engineers adding their own unchecked notions of quality is a super common highly documented and much discussed way to incur mountains of technical debt, waste large sums of money, and deliver projects extremely late.

> I think the disconnect between managers and programmers always stems from if we should look at the programmers as assembly line workers or craftsmen.

The thing is, this is a fear programmers have that business people, by and large, do not share. Managers need programmers to work their craft, they generally don't know how to write code, and know it, and broadly speaking they have a deep respect for people that write code.

When programmers declare they're not going to participate in estimates, or even just drag their feet and complain that estimates are impossible or inaccurate, and when programmers avoid talking to managers and complain that email is preferable and weekly face time has no point, the programmers are the ones putting themselves in the position of being thought of as assembly line workers.

This was only in context of the rather strawman-like interpretation I devised from your original comment. Nothing serious. ;)

> I try to assume that people understand there are always corner cases and subtleties we don't have the time to explain.

Agreed. Apologies for mis-interpretation.

> > But the way you word your responses here makes me think you're more of a business person now and not an engineer. > Is that somehow bad?

No, not per se. But just tell me this -- didn't you ever had a coding problem that legitimately took weeks to even figure out, let alone solve afterwards? Trust is paramount. We should absolutely try very hard to avoid micro-management, wouldn't you agree?

> Moreover, engineers adding their own unchecked notions of quality is a super common highly documented and much discussed way to incur mountains of technical debt, waste large sums of money, and deliver projects extremely late.

I agree that this is sadly very often the case. My really badly communicated intent here was to implore you to never forget that there are those of us who work better when given bigger breathing room. Nothing else.

> Managers need programmers to work their craft, they generally don't know how to write code, and know it, and broadly speaking they have a deep respect for people that write code.

This hasn't been my experience but yes, it's anecdotal. In my past, while I was still working in an office, the general consensus was that the programmers are "the nerds" and we "need to be put back in reality" and we will somehow go to a dark corner and do something extremely bad if left unchecked for one hour. Needless to say, this didn't work out well. And I am not talking about one organization. I am talking about five past employers.

> ...the programmers are the ones putting themselves in the position of being thought of as assembly line workers.

Mmm, I think this puts the things on the wrong foot and sounds somewhat vengeful.

IMO if programmers are good communicators, are clear and upfront, realists and not grumpy asocial techies only, the need for daily or even weekly standups can be easily eliminated.

Yes, I've had lots of large problems that took weeks & months to solve, I'd say hundreds in my career so far. And at times I've desperately wanted people to not bother me while I solve them and stop asking for status reports and just trust me.

I've argued with PMs so fiercely over this, they've put warnings in my personnel file that followed me for years. I've had jobs where the daily status report for a 1 month project took two hours of work per day, and I tried to explain that the overhead meant it would take a full extra week to complete the job. It didn't matter, and I was wrong, and because I'm stubborn, it took me a long time to realize why I was wrong. I was optimizing for my own experience, and my own efficiency, and not for the team's. That's the problem with the manifesto.

Never once have I had a multi-week problem where I delivered the work without either the direction changing or else delivering a solution that was incorrect and had to be partially or completely redone. Never once have I seen another programmer start down the path of a weeks or months long project who didn't require a course correction within days. Usually the problem is incomplete or misunderstood requirements, frequently it is unforseen complexity & unanticipated consequences, sometimes requirements actually change.

My experience has been that when a smart, well-intentioned, and trustworthy programmer (including myself) works on a problem without review for more than a week, it has always resulted in delivery of something that didn't solve the problem, because the problem itself was not understood.

I now believe it's absolutely critical to continue talking about what the goals are regularly, and what the solution needs to do. Clear communication is harder than it seems, and you can agree completely with someone on very specific implementation details for hours and hours one day, only to find out there was a huge and glaring difference of vision the next day.

The efficiency gained by avoiding a 1 hour weekly meeting is lost in very large multiples when the solution is incorrect, and the probability the solution is incorrect is at least proportional to the amount of time it takes to solve.

This is why it's a mistake to equate a manager's desire for regular meetings with a lack of trust, and why regular checkins are not micro-management. Micro-managing is when someone tells you how to do your job and hovers constantly and repeatedly requests bad implementations. I've never had a real micro-manager and I suspect they're extremely rare. A weekly or even daily short status report isn't micro-managing. But being asked what you're doing frequently is often mistaken for micro-management, and a lot of programmers think they're being micro-managed when they aren't.

> My really badly communicated intent here was to implore you to never forget that there are those of us who work better when given bigger breathing room. Nothing else.

I understand completely, and I think this is what the manifesto is saying too. And it's what I want when I'm writing code too. But getting that breathing room and catering to our individual comfort and efficiency doesn't actually help the team as much as you hope, and it can and frequently does do real damage.

Have we forgotten brain context switches penalty? Is there anyone out there who still thinks they are a made-up problem? While you as a manager are in the groove of managing spreadsheets and timelines your entire workday and having a small meeting here and there is mostly not interrupting your overall thought process and vision for the company, a dev being regularly pestered is absolutely destroying their performance. Your job is working with people and the formal tools to manage people -- even if you do 40 small tasks a day you're still mostly on a single reality plane. We need to build mental pictures of a system, simulate how it works, produce a theory what we should do and then start doing it and validating our ideas; 2-3 interruptions on any stage of this process and that forces us back on an entirely different reality plane, and the whole thing goes in flames and we have to rebuild it in our heads again. Very often this leads to forgetting very good ideas on how to address a problem (or add a feature), too. How is that helping you and the organization you manage exactly? This is a somewhat directly measurable loss of productivity.

You also admitted this is about trust but also insisted programmers shouldn't treat often check-ins as lack of trust. Well, I can turn this right back at you -- I insist that they are a lack of trust, so please leave me alone; I am a really good professional, I have a lot of skills outside the programming area and I dare to think I have a good chunk of emotional intelligence in me as well. Why is your opinion on this weighing more than mine? I'd say, try me. I'll prove myself to you if you make one compromise about how you work with me.

^ Have you worked with a person like this? I mean, person who actually delivered after being left alone? I've had plenty of such people in my work. (Admittedly, there was also a large number of fakers and posers, of course.)

I also strongly disagree that all programmers left alone tend to lose focus and work on made-up issues. Most of them -- sure, you'll never hear me dispute that. All? No. Many of us go through that phase, yes, but you seem to forget that not a small amount of us emerge of the other side of that labyrinth victorious. If (1) you are working on something very tightly integrated with other people's work AND if (2) you all make good progress each day, then I'll agree that quick daily syncs are very valuable, they prevent duplication of efforts or coding against the wrong assumptions. But if the above two conditions aren't satisfied then no, in my eyes it's just the manager forcing a process out of context. That's like insisting the temperature outside is a stable 20^C every day, 365 days a year.

The part that's concerning me here is that you seem to want to shoe-horn a singular process on different kinds of people. If you were my supervisor, I'd not be okay with that.

I think I also said that I'd been wrong about that, didn't I? I was there and I don't think it was micro-management. It ended up being a valuable experience for me that has made me a better engineer. Given the amount of overhead and the details of what happened, the "why" is an interesting story with a surprise ending in my book.

> Have we forgotten brain context switches penalty? ... This is a somewhat directly measurable loss of productivity.

We have not forgotten, it just turns out to be often negligible compared to the penalties of solving the wrong problems and failing to work as a team. Not always, but often enough that context switches definitely are not the biggest impediment to productivity.

> You also admitted this is about trust but also insisted programmers shouldn't treat often check-ins as lack of trust.

You misunderstand again, I was demonstrating that I used to think that it was lack of trust. I now know that it was not a lack of trust, frequent time-based communication is a necessary part of getting a job done right. I was given more trust than I'd realized, and my complaints about overhead actually eroded some of that trust. I am pretty sure that asking managers to talk to you less, and complaining about estimates is more or less guaranteed to make managers trust you less. Assuming that requests for communication equals a lack of trust will take you to bad places. But hey, your mileage may vary, maybe I'm wrong. You don't need to listen to me, you are on your own journey and you will learn your own lessons. Let me know if you find out differently.

> The part that's concerning me here is that you seem to want to shoe-horn a singular process on different kinds of people. If you were my supervisor, I'd not be okay with that.

What singular process is that, do you imagine? Communication? You are absolutely certain that what I've talked about is more rigid and limiting than what's in the manifesto? You are so sure I'm wrong that you feel justified in starting to make your arguments personal? Would you bring what you wrote above to your next job interview and expect it to improve your odds?

I think we're both generalizing extreme cases. I don't find myself in a strong disagreement with you -- only on semantics and/or specifics.

As for an interview, I am very open about what things I don't find okay if I manage to detect them during the interview. I don't however go out of my way specifically to list my requirements since that comes off as being a douchebag and I very much prefer adaptation and mutual compromise if we start working together. I am not afraid to lose an opportunity if I get red flags. The interview is, after all, a mutual process.

> Assuming that requests for communication equals a lack of trust will take you to bad places.

No, please. I never said that. I am saying the following: if things go really well and expectations and promises aren't broken, I'd expect you to ease off the regular meeting requirements. Nothing more, nothing less. Enforcing a fully linear and regular process is in my eyes unrealistic and I'll return to my previous analogy once more -- it's like pretending that the weather is solid 20^C every day, 365 days a week.

Communication and trust are paramount. Everything else comes after that. I have long ago put myself in the shoes of the managers and I do understand their needs. What I don't understand is the insistence of flat processes without any adaptation to (1) the current work load and (2) individual specifics.

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

Usually things end up being inefficient precisely because there are no or few people who understand the totality of a process or sales, from idea to design to implementation to sales to support and collections.

That takes talking to other people, and learning about what they do and how they do it and why they do it. I've been in some orgs where that sort of "cross talk" is seen as subversive, likely because it tends to expose inefficiencies that are politically introduced as a way of controlling territory or power.

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.

Well, only if you consider them to be separate. A more nuanced view would see politics as just one manifestation of economics.

http://www.investopedia.com/terms/p/path-dependency.asp

[1] http://www.theconceptsproject.com/chestertons-fence/

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.

This is the hardest lesson to learn for fresh young engineers. Their job isn't to create wonderful new designs, it's to serve the needs of their company - which may involve creating wonderful new designs, if they're lucky, but it may not.

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

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

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

Engineering exists in corporate contexts to serve the purposes of the organization. If you believe that the entire focus of any engineering project should be crafting theoretically-robust software, you're either going to have retire early and pick it up as a personal hobby or go into academia.

That's a strawman crafted by introducing a false extreme dichotomy. I don't think anyone claims they want to produce "theoretically-robust software". 99% of all programmers I've ever met and spoke with in real (or virtually), agree there's no such thing.

What's discussed here (which admittedly is off on a tangent derived from the OP) is questioning the value of rushed software. There's a balance to be struck there and bending over to the managers and always trying to squeeze more in less time is always ending up in flames. I still don't get it why so many people, probably you included, have trouble understanding this very simple (and well documented in the recent history) truth.

I think the problem is you're conflating a recognition that software needs to get done and shipped with the surrender of good craft. Good craft _necessarily includes_ a recognition that your purpose of an employee is not to write beautiful software, and then to move on to make something good within reasonable time constraints anyway. Not perfect, not without warts or things to improve, but good.

When your chain of command knows you understand your job is to serve the company and not to indulge in impractical engineering excesses, they'll trust you much more and be more willing to give you the freedom you need to do something well. Balking any time they ask for a timeline is not the way to establish this.

That's the keyword indeed -- good software. Not amazing.

What I kind of got from your previous comment was that if you resist being micromanaged, you're not a good professional. Apologies, it seems I misunderstood.

IMO a good professional has to also know to hold their ground here and there. Nobody respects a bottom-licker who bows down at every request, that's basic human nature and no formal processes can nullify us reacting animal-like in these situations sometimes. I find that when I argue with my superiors that I am given too unrealistic of a deadline and argument myself well, their respect for me actually grows and they start trusting me more and pester me less. One of them told me "I love it that you don't bullshit your way out of meetings where you have to make a tough sell" and I think that sums up my approach best.

TL;DR -- if both sides are willing to compromise to find the best value for the programmer's time and managers do NOT relentlessly insist you do things in the shortest time possible, then things go really well.

However, tasks that improve engineer productivity, like speeding up the test suite, or adding automated tests, removing unneeded code, a badly needed refactor on a critical piece of code can not only makes new features quicker to develop, but also makes the technical improvements quicker to develop. Features have the opposite effect.

A competitor shipping crap first is not a big threat, unless you compete in making crap.

There are multiple historical examples to draw from.

I think the better case here is where business and engineering can talk in meaningful terms about the difference between technical debt and longer-term simplicity and productivity of a system.

Painfully true

As a software developer for a commercial organisation, the work is to make profitable software. Profitable does not mean the same thing as elegant.

There is a huge amount of skill involved in creating profitable software, because it involves a huge number of judgement calls about what matters, and what will produce the most bang for the least buck.

Creating beautiful, elegant, software is easy when there are no time constraints. Beautiful, elegant software is wonderful stuff when it's part of a non-commercial open-source project that we all use and depend on.

That's not the stuff most of us write. We write code that's part of a product that a limited range of customers will run, paid for by a limited budget. We very much need to be good at our work, which may well involve writing shitty code quickly if that's the most profitable thing to do.

Caring about our work is not the same thing as writing elegant code.

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

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.

I did eventually escape, but there really wasn't a safe way to do so quickly.

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

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.

    > Developers aren't actually
    > special snowflakes

    > and they sure as hell
    > shouldn't be hiding away
    > work they'd like to do in
    > what are nominally feature
    > cards

That's their job.

    > then get grief later when
    > the points didn't directly
    > map to time

Maybe the fact that most developers never really see well-implemented Scrum process says something extremely important about Scrum and the human nature. Namely that they don't click well together.

I wonder why are people so stubborn when it comes to having to take a step back and re-evaluate their process?

    > deal definitions will always
    > exist and conversely, will
    > never be implemented

    > Maybe the fact that

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.

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.

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

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

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

I realized that I just fundamentally misunderstood how I should be doing estimation. Previously, the way I did it was "well it sort of feels like a day, I guess". Now, what we did was:

a) Before estimating, have some certainty about what exactly we want the feature / behavior to be. This is usually the top mistake teams make, and it's a problem. This can come from talking to users, designers, whoever. Focus groups, user testing, design sprints, whatever you want. This all happens before the estimation starts. If you're figuring out what a feature should be doing while estimating time, or even worse, while implementing the feature, you've failed already, and all bets are off in terms of estimates, but also just in terms of finishing things in a reasonable amount of time and in terms of actually building a feature that an end user wants, as opposed to building what's convenient to the developer at the time. It also helps the developer because it's not actually fun to be figuring out requirements in the middle of writing code.

b) Now that you have certainty, you go do research. Have you done a thing similar to this before? Pull up the ticket. How long did it take? Whose time did it take? What were the pitfalls, if any? Then go look at some code and start thinking about implementation: what would this take? What modules / files would you have to change? Does this have architectural implications? Should you be talking to anyone else? When you start doing this, you force yourself to think about the actual, real work to be done, and away from the realm of hazy bullshitting. You find all sorts of weird issues you didn't see before, which helps your estimates be much more accurate. Put these in the ticket, to ask your teammates about later. You find things about the task itself that are vague. Note these in the ticket also, and remember to ask about them later. You also can immediately tell if you need someone else to do something before you can get started, so make a separate ticket for that and assign to the appropriate person. Also, resist the temptation to write code just yet. Finally, now, you can make an estimate. Some people prefer t-shirt sizes, others prefer hours. It doesn't matter, just pick one, have it standard across the team, and go with it.

c) Now that you have a clear set of features and a reasonably clear roadmap, you and your team sit down together at a table. You discuss work that needs to be done. You bring up issues to each other about tickets. If any of them get solved (often does), then great. If not, it gets moved to the next sprint, along with anything that depends on that. If it's urgent, you make a new, separate "research" task with the purpose of figuring out the remaining details, and leave some room at the end of the sprint to possibly be able to pull in that new task, once it's well-defined. You never pull in a task for a sprint by making up a bullshit estimate for it, regardless of top-down pressure. Every time we violated this rule, it ended up biting us in the ass. Finally, now with actual estimates, you as a team make decisions on what takes high-low priority. Then you figure out blockers: what needs to be done first so other team members can work on things, and you focus on those first. Then there is stuff like

Anyway, if you start doing this seriously, in a few sprints you'll be hitting estimates like clockwork. It's actually a very satisfying feeling to have clearly defined tasks and execute as a team. And for reference, a) was done by our manager / designer before the sprint planning. b) and c) used to take us around half a day (3-4ish hours) total to plan a 2 week sprint. All in all, very worth it.

edit: Final rule here is that the people who are doing the work decide on the estimates themselves. Never management. Other engineers get to weigh in, but only to make the estimate larger, not smaller. This takes off a lot of pressure from engineers in terms of delivering. At first, the focus is to plan a sprint and just deliver on what you planned. If that means taking on less work, and you finish early, then fine. You can always take on more work once you're done. Once you can always deliver what you promised, only then do you start adding more work. This way, everyone is realistic about the work that can be done, and overpromising is less of an issue. If there is something urgent, the manager gets to say "hey look, this is what we're committing to this week, these are what we'd have to not do to do the thing you want. This is a level of transparency that usually makes stakeholders happy, and at that point they're free to make the decision, as opposed to being angry later.

The problem with that is that we have no insight on how much they'll be wrong and our reputations as developers get hung out to dry on those.

I think its better to work with what you can control. You can size stories (S, M, L, XL) to the point of consensus with everyone in the room; so work with that.

The next best thing you can do is to agree to work diligently with your team to implement those stories, without waste, towards a stakeholder and team agreed _definition of done_.

I would only ever say an estimate was wrong if it was widely out and you could have reasonably been a lot more accurate with a small amount of effort. Once people accept that some estimates will turn out to be too high and too some too low but they should mostly balance out instead of treating them all as very accurate it should be less of an issue.

> The problem with that is that we have no insight on how much they'll be wrong and our reputations as developers get hung out to dry on those.

That's a team problem with how estimates are treated that has to be fixed though. Estimates are estimates and not reading the future. If developers are treated like that for estimates the same problem will just manifest with whatever other system you come up with.

> I think its better to work with what you can control. You can size stories (S, M, L, XL) to the point of consensus with everyone in the room; so work with that.

What would you do for a fixed price project then where the client wants an agreed figure to pay for a delivered product (e.g. a few months of work)? If you're too high they won't accept the contract and if you're too low you'll lose money. You cannot avoid estimates here.

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.

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

Perhaps try sizing via t-shirt sizes, S, M, L etc. and then build up some team historical data on how long it takes everyone to get something all the way to production.

The both the business and development team can point to the historical data set as the best indicator of history repeating and we can leave hunches and guesses out of it.

This correlates with your S, M, L thoughts. The Product Manager can then prioritise based on these (i.e. these three single point stories deliver more value than that three pointer) and points are internally calibrated over time.

I have to say though, that my team doesn't really have "deadline" releases and the PM releases any time we deliver something of value to our users, so it helps relieve some of the burdens about estimating i.e. When I point, I don't really care if the points don't end up reflecting time.

I dunno.

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

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.

But it's a lot easier for a manager to conceptualise how long a piece of art will take to do than a piece of code.

One significant difference is that you can just look at a drawing and know if it's okay or not. There's no test suite for graphic art. Drawing outside the lines is a stylistic choice. Compiler errors are not.

The stuff a graphic artist will be fastest at, and for which estimating will be easiest, is stuff they've done thousands of times before. Most programmers aren't writing code they've written thousands of times before, unless they're not paying attention.

Out of the creative arts field, I think programming is probably most like creative writing. The grander the program, the grander the equivalent narrative. Unlike a picture, you can't just look at a book and know if it's written properly, you have to read it through. Not only do you have to worry about grammar, you also have to be concerned that the narrative is internally consistent, and that it features the themes, characters, and dramatic situations specified in the brief.

Of course, the analogy still isn't exact. A novel doesn't actually have to be internally consistent, and the book doesn't crash if there are spelling mistakes. In fact, many novels written without taking spending the time and money to edit it properly will have plot holes or grammatical errors. A reader can fuzz past it, but a computer can't.

Ask a writer how long it will take to write a novel that is totally internally consistent, leaves no plot threads unresolved, and has no grammatical errors. They'll tell you it can't be done to schedule.

But yes, creative writing works as well. And creative writers are given deadlines.

This "Longflow Manifesto" would be fine (in my opinion) for programmers who are happy to get paid only on delivery, but how many are happy with that?

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

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.

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.

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.

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

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.

1. https://pragdave.me/blog/2014/03/04/time-to-kill-agile/

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.

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.

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

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.

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.

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?

It still puzzles me how these two seemingly mutually-exclusive notions can coexist in a single person's mind.

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?

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.

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

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

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

* What are ways to mitigate these dangers?

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.

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.

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.

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

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

I wonder how much worse it could have been. The only thing really competing with JavaScript in its early years was VbScript. If Netscape didn't make a solution, Microsoft probably would have. And that would most likely have been something like VbScript. Not infinitely worse, but quite a bit worse.

I could not find a reference to RPG's famous essay here, so I'm guessing it will be new to some folks.

Mind you, WiB can be taken as license to do worse, which is sometimes just worse. JS in ten days actually got worse in the next 20 as I had early adopters ask for sloppy == and so on, and I gave them what they wanted. My fault for caving, but also part of the gamble to start fast and grow quickly.

What people miss about the Web is the backward compatibility constraint, very real at almost any scale and reinforced by browser competition. As I RTed recently, "replace" is spelled "e x t e n d" on the Web. This is a lesson Dart and other well-heeled projects ignored, in spite of many (including inside Google) telling them so.

So WiB means get on first, worse enough that you are first, better enough over time that you don't get replaced. By that criterion, JS is a huge success. Haters even turn around thanks to the language evolving toward ever-better extended editions such as ES2015 and beyond. See http://node.green/.

But your point is also good. My first big application was basically sunk because a coworker froze up on making some functionality because he couldn't figure out a way to do it perfectly - that is to say he knew no matter what that he would have to rewrite that functionality in 6 months to a year, as a consequence he spent nearly 2 months not doing anything trying to figure out how he wouldn't need to do that rewrite.

You should know there are some of us who are quite disciplined and self-reevaluate fairly often. If I was on the place of your engineer I'd spend 2 weeks at most and then just think it through the weekend -- why is this taking so long? Am I overthinking the possible future plans for this feature? (Very likely.) What are the main hurdles? (I'd write them down and analyze them one by one.) What makes me think a quickly put together code isn't good enough?

It seems you had a junior developer put in a situation too big for their non-technical abilities. Again, this is nasty and I am sorry that you have been bitten by that.

But please have in mind there are many other programmers out there who can do a much better job from the organizational (non-technical) side of things.

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.

More users is obviously good, as are more releases, but more commits? More repos? More LOC?

Like the way Lean defines "waste" (muda), the meaning of "quality" and "quantity" in the world of software are highly context specific (and should usually be tied to customer perception).

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.

http://agilemanifesto.org

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.

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.

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.

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

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

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

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

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

To keep myself from rambling, I'll say this: making accurate estimates and connecting them to timely delivery are two huge, but different, problems.

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)

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.

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

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

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.

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

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.

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

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.

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.

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.