4 ms·
> Using the author's city analogy, they appear to be advocating that all city workers need to have a vision of the whole city plan for any task they they are do
by steve_taylor 8y ago
> Using the author's city analogy, they appear to be advocating that all city workers need to have a vision of the whole city plan for any task they they are doing, that doesn't scale.
For most projects, it does scale. The problem with almost all software development analogies is that they attempt to draw parallels between design and manufacturing. Software development is much more design than manufacturing.
A more suitable analogy would be art. Imagine a group of artists commissioned to create a painting. The designers decide, upfront, the main elements of the painting, then someone else breaks the work down into tickets based on those elements.
Unless extremely well managed, the result is likely to be hideous and the project is likely to have a high turnover of artists. This is pretty much what happens in most software projects. The real problem, as this article identified, is that a bigger picture perspective is needed. Unless a project is crystal clear about the big picture, everyone will have their own big picture and build features accordingly.
- TeMPOraL 8y ago> The problem with almost all software development analogies is that they attempt to draw parallels between design and manufacturing. Software development is much more design than manufacturing. Also construction. The way I see it, what programmers do is not constructing a building, they're doing the architecture (and wiring plans, and landscape plans). Construction is what compilers do.
- deleted 8y ago[deleted]
- KaiserPro 8y agoI've worked with artists, and that's precisely how it works. https://www.foundry.com/products/flix/new-releases https://www.foundry.com/products/flix/new-releases is basically a visual pinboard. It allows storyboard artists to collaborate, give crit, and iterate on an entire movie. Later on in the pipeline, the modelers, animators, lighters, texturers all have to take the storyboard input, combine it with the vocal cues and make an artistic thing. There is an agreed upon style guide, with a very close feedback loop (dailies, weeklies and monthlies). all managed by something like https://www.shotgunsoftware.com/ https://www.shotgunsoftware.com/ or ftrack. which is basically Jira + MS project love child. Its the same with software, There is a style guide (well should be, you can use this tech, with these standards, deployed and monitored by these tools) which lives outside of Jira. Jira is then both tracking tool (so the buisness can see progress) planning tool, so that decisions can be traced, tracked and adjusted, and notebook. I can understand the hate for Jira. I was at a company where we changed workflow every sprint. Its dispiriting, annoying and wasted on average .75 of a day a week. Thats not the fault of Jira, that the fault of the people who take the religion of AGILE and impose it. Process should be mapped to the system, not the system mapped to the process.