4 ms·

> building a generic project management and tracking tool is a really difficult, hard problem I would say building a good one is an impossible problem, because

> building a generic project management and tracking tool is a really difficult, hard problem I would say building a good one is an impossible problem, because of conflicting needs both across and within companies. The primary job of Jira isn't to help work get done. It's to give managers and executives feelings of knowledge and control even when that makes everything worse. You don't need fancy planning systems to get good work done. Indeed, I think it's the opposite. I've done many years of work with only index cards. E.g.: https://williampietri.com/writing/2015/the-big-board/ https://williampietri.com/writing/2015/the-big-board/ As Poppendieck has talked about, we live in a "Tyrrany of the Plan" age, but that's not necessary and it often makes things worse: https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of-the-plan/ https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of... I think this has happened because of the rise of managerialism, where management becomes a self-justifying caste. : https://en.wikipedia.org/wiki/Managerialism https://en.wikipedia.org/wiki/Managerialism

NikolaNovak 4y ago
>>"You don't need fancy planning systems to get good work done" I mean, as a single individual, in some circumstances, sure. If we think a bridge or railroad or spaceship get built without fancy planning, we've taken our software engineering paradigm to new level of delusion. Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing, but we feel in software we are just too darn special of snowflakes to need or agree to that? Sorry if I got your comment way out of context or scope, but it just struck me as a very circumstantial statement, but one that is bandied a lot as a generically applicable one - which it isn't. For many things you need very fancy planning indeed.
- BlargMcLarg 4y ago
  I'll ask you the reverse. What proof is there we absolutely need all this to function? If people are so sure of this, surely they can substantiate it with more than just rationality. If the similarities are fine, just pull that information from the other disciplines you insist know better than the "special snowflakes". >Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing You're conflating "needing to align thousands of people" with "needing a fancy system which pulls everyone in its web to deal with multiple times a day". If anything, construction shows just how little ICs need to know to function. You don't boggle your construction workers with bureaucracy, you take it away and let architects, managers and foremen deal with it.
  - urthor 4y ago
    If you've worked in large construction, you'll realize just how many project managers large projects need to function. There are an incredible amount of project managers running from place to place on a construction project keeping teams in line. Construction work, design blueprints, government regulator, there are SO many teams and SO many project managers running between them. JIRA is absolutely a net positive in that environment. A centralized system like JIRA alleviates that.
    - BlargMcLarg 4y ago
      You haven't addressed the part where the ICs have to be part of the system so thoroughly. You've only addressed that project managers need to communicate with one another and with their teams, and you've only done so by using anecdotal evidence, before drawing a conclusion that JIRA is a net positive. Again, give some actual proof. It's about time we stop clashing rationalities and face the music. If it's this easy to come to a "rational conclusion", it shouldn't be much harder to pull evidence.
- 8ytecoder 4y ago
  It is an issue in all fields. The reason why we have delays in major infrastructure projects and why software projects are notoriously hard to plan both boil down to unplanned and unexpected changes to requirements. The fact that it’s easy to change software makes it that much more vulnerable to last minute requirement changes. If something is exactly the same we can just reuse existing software and we don’t call that “development”. It simply becomes “buying” instead. And that makes most software development explorative in nature. Now tell me how many explorative real world, non-software projects have a well-adhered to and exact plan.
  - wpietri 4y ago
    You're exactly right about software being exploratory, but I think the whole notion of fixed, up-front requirements is part of the problem. In the lean analysis, the problem isn't changing requirements, which is a natural consequence of changing circumstances and people learning over time. The problem is building up a large inventory of poorly-tested, underinformed plans and then doing a lot of work based on them without taking advantage of the opportunities to learn. Especially here on HN, we know that startups don't succeed because they come up with a fixed initial plan and then spend years marching to it. Instead we have all set of techniques for releasing early and often so we can see what really works for users. A key competitive advantage for startups is how their fast OODA loops allow them to run rings around larger companies that slowly drift into being very plan-based.
- wpietri 4y ago
  I was talking about software, not spaceships. Software, being soft, is fundamentally different. However, you should watch the Poppendieck talk I linked. The Empire State Building had construction start before they finished designing it. The waterfall hallucination, where people imagine perfect results come from perfect plans perfectly executed, has been hugely enabled by software. But if we look at the actual results of heavily planned activities, like buildings, roads, and weapons development, the track record is terrible. So if modern planning techniques don't work well even in areas, like construction, that they are most suited for, then it should be no surprise that people are skeptical when they are applied to domains that are very different, like software.
silisili 4y ago
I agree, but wish/think this can change if the product is good enough. Meaning, if someone could write a super fast, easy to use, minimal planning/task tracker, with a good set of reporting, I feel it could coerce companies to adjust their models to use it. It's a risky venture, but products like Slack, Docker/K8S, git, and VS Code gained wide adoption without trying to cater to existing organizational processes.
- wpietri 4y ago
  I hope you're right, but I'm suspicious. For the ones I know well there, they worked because the didn't need permission from the powerful Git, Slack, and Docker were definitely like that in the early days. But planning systems are chosen by the powerful and cater to their needs first. There are plenty of minimal planning tools out there. Github issues, for example. Or I use KanbanFlow quite a bit. But having driven adoption of simple tools, I think you at least need an environment of benign neglect, as with a skunkworks project, or a tech project at a non-tech company. From what I've seen, in a lot of companies systems like Jira are too entrenched and too visible to management to allow for guerilla-style adoption of something that's more developer/worker friendly.
mountainriver 4y ago
Yes this is exactly right, it’s all about top down feeling of control. You can very easily manage even a large organization with just basic Kanban boards

NikolaNovak 4y ago

>>"You don't need fancy planning systems to get good work done" I mean, as a single individual, in some circumstances, sure. If we think a bridge or railroad or spaceship get built without fancy planning, we've taken our software engineering paradigm to new level of delusion. Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing, but we feel in software we are just too darn special of snowflakes to need or agree to that? Sorry if I got your comment way out of context or scope, but it just struck me as a very circumstantial statement, but one that is bandied a lot as a generically applicable one - which it isn't. For many things you need very fancy planning indeed.

BlargMcLarg 4y ago
I'll ask you the reverse. What proof is there we absolutely need all this to function? If people are so sure of this, surely they can substantiate it with more than just rationality. If the similarities are fine, just pull that information from the other disciplines you insist know better than the "special snowflakes". >Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing You're conflating "needing to align thousands of people" with "needing a fancy system which pulls everyone in its web to deal with multiple times a day". If anything, construction shows just how little ICs need to know to function. You don't boggle your construction workers with bureaucracy, you take it away and let architects, managers and foremen deal with it.
- urthor 4y ago
  If you've worked in large construction, you'll realize just how many project managers large projects need to function. There are an incredible amount of project managers running from place to place on a construction project keeping teams in line. Construction work, design blueprints, government regulator, there are SO many teams and SO many project managers running between them. JIRA is absolutely a net positive in that environment. A centralized system like JIRA alleviates that.
  - BlargMcLarg 4y ago
    You haven't addressed the part where the ICs have to be part of the system so thoroughly. You've only addressed that project managers need to communicate with one another and with their teams, and you've only done so by using anecdotal evidence, before drawing a conclusion that JIRA is a net positive. Again, give some actual proof. It's about time we stop clashing rationalities and face the music. If it's this easy to come to a "rational conclusion", it shouldn't be much harder to pull evidence.
8ytecoder 4y ago
It is an issue in all fields. The reason why we have delays in major infrastructure projects and why software projects are notoriously hard to plan both boil down to unplanned and unexpected changes to requirements. The fact that it’s easy to change software makes it that much more vulnerable to last minute requirement changes. If something is exactly the same we can just reuse existing software and we don’t call that “development”. It simply becomes “buying” instead. And that makes most software development explorative in nature. Now tell me how many explorative real world, non-software projects have a well-adhered to and exact plan.
- wpietri 4y ago
  You're exactly right about software being exploratory, but I think the whole notion of fixed, up-front requirements is part of the problem. In the lean analysis, the problem isn't changing requirements, which is a natural consequence of changing circumstances and people learning over time. The problem is building up a large inventory of poorly-tested, underinformed plans and then doing a lot of work based on them without taking advantage of the opportunities to learn. Especially here on HN, we know that startups don't succeed because they come up with a fixed initial plan and then spend years marching to it. Instead we have all set of techniques for releasing early and often so we can see what really works for users. A key competitive advantage for startups is how their fast OODA loops allow them to run rings around larger companies that slowly drift into being very plan-based.
wpietri 4y ago
I was talking about software, not spaceships. Software, being soft, is fundamentally different. However, you should watch the Poppendieck talk I linked. The Empire State Building had construction start before they finished designing it. The waterfall hallucination, where people imagine perfect results come from perfect plans perfectly executed, has been hugely enabled by software. But if we look at the actual results of heavily planned activities, like buildings, roads, and weapons development, the track record is terrible. So if modern planning techniques don't work well even in areas, like construction, that they are most suited for, then it should be no surprise that people are skeptical when they are applied to domains that are very different, like software.

silisili 4y ago

I agree, but wish/think this can change if the product is good enough. Meaning, if someone could write a super fast, easy to use, minimal planning/task tracker, with a good set of reporting, I feel it could coerce companies to adjust their models to use it. It's a risky venture, but products like Slack, Docker/K8S, git, and VS Code gained wide adoption without trying to cater to existing organizational processes.

wpietri 4y ago
I hope you're right, but I'm suspicious. For the ones I know well there, they worked because the didn't need permission from the powerful Git, Slack, and Docker were definitely like that in the early days. But planning systems are chosen by the powerful and cater to their needs first. There are plenty of minimal planning tools out there. Github issues, for example. Or I use KanbanFlow quite a bit. But having driven adoption of simple tools, I think you at least need an environment of benign neglect, as with a skunkworks project, or a tech project at a non-tech company. From what I've seen, in a lot of companies systems like Jira are too entrenched and too visible to management to allow for guerilla-style adoption of something that's more developer/worker friendly.

mountainriver 4y ago

Yes this is exactly right, it’s all about top down feeling of control. You can very easily manage even a large organization with just basic Kanban boards