5 ms·
Software development cannot be managed like this. This sort of task break downs come from classic management training. The problem most people are unaware of is
by hnaccountme 3y ago
Software development cannot be managed like this. This sort of task break downs come from classic management training. The problem most people are unaware of is software development is more a creative activity than anything else. Yes there are serious technical aspects to it but since the problem is virtual and not bound by any real world limitations, like how civil engineering would be, there isn't one optimal solution. Trying to define the solution before the problem has been properly examined would only limit the final output. Most of the exploration only happens when people actually start coding.
Not having a well defined final output and time is not very relevant for software, mostly because there is no per unit cost. Most managers do not realize this is they are not from a software engineering background. A versatile product can be sold to many different customers without additional development costs.
But since most companies are managed as factories, all the processors will ultimately create a very limited product targeted at a specific customer. What the big tech companies have avoided is this .
- rolisz 3y agoYou'd be surprised how much creative tasks like 3D modeling and creating artwork can be broken down into tasks that are very well defined and can be estimated quite correctly.
- makeitdouble 3y agoI think it would fall down the same lines if you required a coherent world and high quality for each of the models you create. That would mean redo models that don't fit the whole piece, endless tweak some models that are really difficult to get right, sometimes do swiping changing across all the parts because as a team you realize something is off etc. The balance will be between delivering something within a time frame, and delivering the quality that was requested/expected.
- heisenbit 3y agoThe difference is that you break down software into smaller and smaller bits and then find a small bit that needs data from a far away small bit. I suspect this happens less with mechanical systems.
- ssivark 3y agoIf that’s the case, what makes the work “creative”? (It’s possible two sets of people use the term to mean two different things)
- leetrout 3y ago> But since most companies are managed as factories, all the processors will ultimately create a very limited product targeted at a specific customer. Do you have more examples of companies that are not feature factories? It seems the entire industry has adopted this pattern.
- hackerlight 3y agoBell Labs? Changing the topic from software development to R&D: the granular task oriented view is generally not good for greenfield research endeavours. It's a form of premature optimization. You're calcifying the search space and reducing flexibility to pivot immediately based on expert intuition and hunches. That being said, a coarse task orientation is necessary to keep people vaguely pointed in the right direction. The best resolution (time horizon) for task orientation depends on what you're doing.
- stana 3y agoInteresting you mention 'intuition'. I feel it is a big part of software development as you gain experience and it flows through as you are doing the work and would be tough to plan for. Also remember one of my colleagues complaining after work 'code just not flowing freely today'. And then there are times when you feel you are in the zone, which would definitely be the creative element.
- CRConrad 3y ago> Bell Labs? Too bad that's pretty much the only such example that has been touted since... The 1960s, is it? And that it was, IIRC, recently either shut down or announced to be shut down sometime soon. Thus, using this as an example seems, if anything, to illustrate not that "there are too!" but "there are dwindingly few".
- n4r9 3y agoDo you have any pointers for guides about how to implement this sort of methodology in software-based R&D? I'm currently in a small, partly research-focused team as part of a larger tech company, and it's proving a struggle to align our work with the rest of the dev squads who do all their work in 2-week sprints with max-2-day tasks. I'd love to better understand how research teams tackle this problem in other companies. It would be amazing if I could present an alternative strategy to management that's worked elsewhere.