This manifesto looks to be far more promising than previous manifestos in the software development industry. It’s called the Longflow Manifesto and it advocates a lot of ideas that will be found controversial by managers but would be supported by software engineers.
Here are the overarching ideas it advocates for:
- Focus on high quality software engineering
- No estimates, they are usually far too inaccurate to be worthwhile
- Little or no meetings, give people time to work
Just in case anything happens, we’re going to re-post the Longflow Manifesto version 1 below. If you are a manager, read it and feel a shudder. Yes, the software developers and web developers and software engineers are getting smarter, they’re getting wise to the game, they know when they’re being treated like factory workers and soon they will know how to fight back against micro-management.
There are over 460 stars, bookmarking it on Github. That’s 460+ more software developers who are aware that they are being micro-managed and treated like robots rather than as the creative, craftspeople and professionals that they are. They don’t have to be monitored every minute of the day like they’re children in daycare; they don’t have to be told exactly what tasks to do; they know how to figure this out and how to get work done. You can see this when developers are left alone to work on their own open source projects, they clearly know how to organize larger projects (see exhibit A: Linux). There is no micro-managing going on on open source projects and they usually have higher quality than the typical corporate software that is micro-managed (notice how many companies now rely almost exclusively on open source code).
Developers, read this manifesto and (even if you disagree with some of the points), realize that the power is within you and within your colleagues to change the work environment from a toxic workplace to a healthy place where you are treated as professionals and where you are given the space to work at a higher quality.
Here it is:
The Longflow Manifesto
The longflow model is an engineering-centric workflow for serious software developers, tired of the “Agile”/”Scrum” bullshit.
In the software industry, like in every industry, a business owner does not sell time. A business owner sells a product. However, a software developer bills time worked.
Somewhere, time must be transformed into improvements to the product. The action of applying this transformation to time is called work.
However, the relation between time spent and work done is absolutely not linear. Premature optimization, for example, is a good candidate for a log-like relation, where more and more time is being invested for less and less benefits. On the other hand, good refactoring can use a moderate amount of time for exponential returns over a long period of time.
This is the key principle of the longflow methodology: everything has to be done with long-term goals in mind.
That does not mean no prototyping. That does not mean premature optimization. That does mean quality has a price: time.
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.
It is often impossible to split a task into meaningful smaller ones, even more so before starting the original task. Just like it may be impossible to split a function into meaningful smaller ones, when such function is already coherent and provides a self-contained service.
Have the workflow match the project, not the other way around.
This draws a nice parallel with data-oriented design, where the data is the core and the logic has to match it.
Frequent, time-based interactions between executives and engineers are one of the best way to crash a company.
Having a meeting once in a week/month or other indicator based solely on time is meaningless. It conveys the idea that all the tasks are the same, that all progress must be at a steady pace. It’s also an excellent way to focus more on immediate results than on the long term goals.
Interactions between executives and engineers must be limited in terms of number and frequency.
It’s also best to be as unintrusive as possible : a mail may be better than a meeting in a lot of cases.
Micro-management should be avoided at all costs, because it creates interferences between executives and engineers, and reduces creativity.
Rushes, sprints, crunch-time, etc. are toxic and dangerous.
Quality is infinitely superior to quantity. Software engineers aim to produce working, beautiful, readable code.
By forcing deadlines upon them, they are encouraged to produce “the least dysfunctional” code instead of “the best possible” code. The longflow methodology advocates having medium to large sized meaningful tasks, self-assigned whenever possible, where developers can leverage both technical and problem-solving skills. Have developers write no code at first, but simply think about how they can solve the problem. Or, better yet, asking themselves questions like:
- Is there a problem to solve?
- Can I improve this part of the code?
- Are there tasks I wish I had done differently?
Curiosity and creativity are very important skills for software developers, but these skills can’t develop if there is pressure to release code as fast as possible. It is very detrimental to have long, let alone permanent, deadlines.
Developers should be allowed, and even encouraged, to spend some time learning and toying with new things and concepts. Being able to apply a large variety of solutions and concepts on a problem is crucial for a good software developer. Denying their right to learn will hinder the ability of developers to improve and produce quality code.
- Keep thinking about long term goals.
- Let engineers self-assign tasks.
- Value quality over deadlines.
- Let the engineers do engineering.
- Don’t micro-manage.
- Don’t interfere with engineers more than strictly required.
- Never rush, always think and plan ahead.
- Don’t fear failure.
- Avoid cargo-cults like the plague.
- Keep thinking about long term goals.
- Pick up your own tasks.
- Try to fix bugs before introducing new features, to an extent.
- Try to clean the codebase before introducing new features, to an extent.
- Try to write the best possible code.
- Don’t fear trying something different.
- Think more, write less.
- Always try to learn things, be curious.
- Don’t fear running late.
- Don’t fear to fail.
- Avoid cargo-cults like the plague.
A typical implementation of the longflow manifesto, from the point of view of an engineer, is something like this:
- I pick or create a task.
- I spent a few minutes/hours/days thinking about the task. Do we need it? Have I done something similar before? What does the task achieve?
- If the task turns out to be unneeded, go back to 1.
- If I need to learn something to do the task, I go learn it.
- If I want to learn something new, I go learn it too.
- I think about the task again. I may go back to 4 or 1 if the things I learned changed my mind about the task.
- I work on the task. I may go back to 2 at any point.
- I finish the task.
- I think about the task again. I may want to go back to 2.
- The task is now considered done, but I (or someone else) can decide to work on it at any time, going back to 2.
It may seem messy at first, but a workflow like this is both extremely flexible and extremely good in terms of quality of the code produced, because everyone can improve any part of the codebase whenever they want.
This manifesto was written by Nax.
Feel free to modify it.
Also published on Medium.