5 ms·

I'll never understand why the software development community as a whole seems to have such an NIH attitude to software project management. Meaning, why aren't o

I'll never understand why the software development community as a whole seems to have such an NIH attitude to software project management. Meaning, why aren't our people studying what works in other industries and figuring out how to apply it to our industry? Is it some conceit that software development is somehow truly unique compared to the problems and concerns faced by other industries? That's dumbfounding to me if so. Our industry is barely 70 years old and hardly anybody seems interested in stealing the best ideas and practices from other industries that in some cases have been around for thousands of years.

mattmanser 8y ago
Isn't that what waterfall was? Replicating building a house? Gather requirements, design it, plan it, build it.
- davidkhess 8y ago
  Partially. But I think waterfall has (at least) two major weaknesses. The requirements are textual. They should be visual like a blueprint. A real custom home is typically visited and inspected regularly by the future home owner during construction. An improvement for waterfall would be a periodic delivery to the user of intermediate builds of the product – no matter how incomplete.
  - davidkhess 8y ago
    In other words, waterfall didn't go far enough. Instead of discarding it, we should have continued to improve it.
  - balfirevic 8y ago
    > A real custom home is typically visited and inspected regularly by the future home owner during construction. An improvement for waterfall would be a periodic delivery to the user of intermediate builds of the product – no matter how incomplete. May I suggest you look into this agile thing?
    - davidkhess 8y ago
      I don’t think developing a solid and complete blueprint at the beginning of the process qualifies as agile.
      - balfirevic 8y ago
        With the intention of following the blueprint all the way to the end, user wishes be damned? No, that would not qualify. But it would qualify if you actually delivered partially built product in iterations and incorporate the changes that the client requests as they inspect it, even if you preceded it with extensive blueprinting. Only in that case, it has been found that developing such detailed blueprint is very time consuming and at the same time not very useful. So we don't do it for most kinds of software projects, but not because it's against any agile principles. The original agile principles (I was just getting into software development when they were articulated) really prohibit very few things, if anything at all. But they do emphasize valuing working, useful software over following strict plan. Use planning to the exact extent that it helps you do create such software.
        davidkhess 8y ago
        The only part of the agile approach I like is iterative delivery. First, I believe software blueprints should be put together by people with 15 to 30 years of expertise. Secondly, blueprints for a custom home are completely indispensable and are referred to regularly during construction. I believe one of the reasons why is because they are visual, not textual. I believe software requirements should be the same and then they would be easier to adjust and would retain their value. Custom homes can be adjusted in mid-build. But it is a big deal and you have to get the architect involved and potentially have your plans revetted by inspectors and the city. It's a process that has a high cost. And it should because good blueprints like good software designs are highly dependent internally. I believe every change risks degrading their quality. If you are in a project where there are large numbers of unknowns about the functionality of the project, I highly recommend shrinking the scope to what you know and actually understand. Build that, and then learn from it. Then come back around and start a new "dave's custom home waterfall" (for lack of a better name) process to implement the next set of functionality. Constantly course correcting is a recipe for never finishing and weakening quality. There should be natural impediments to course correction and scope reduction should be used until the unknowns have been reduced to a reasonable risk level.
  - wink 8y ago
    I think this falls flat in terms of imagination. Look at a building shell, even if you have zero clue about houses you can see if they used rotten wood. It looks like it will become a house. The more it progresses.. well, you can easily tell "that door shouldn't be where it is" and so on. Now look at the code generated by $framework via "$tool new project $name". To a non-coder (or even just not using that language) it's not really discernible from a 90% finished product. Your house doesn't turn invisible because looked at it from the back. Also house construction follows certain "easy" patterns a 5 year old can grasp - you need to start at the bottom, you can't put the paint on before the walls are in, etc.pp - give a coder of 10 years a project in another language without documentation and you won't hear anything in the direction of "it's more 10% or 80%" unless spending days. I'm not saying people building houses have an easier job - but it's palpable.
    - davidkhess 8y ago
      To the first concern - that’s why I recommend you deliver (ideally) weekly intermediate builds of the product to the end user. Typically an underlying issue will begin to surface pretty rapidly. To the second concern, first, let’s get on the same page. When I use the home analogy it’s in regards to a custom home - not a from-plan/spec home. To your point, I believe well developed software should also have strong and obvious patterns that are reused in many if not all other projects.
    - TheCoelacanth 8y ago
      It is not remotely that simple to tell if a house is a bad one. That is why people almost always get a professional inspection before they buy one.
balfirevic 8y ago
> Meaning, why aren't our people studying what works in other industries and figuring out how to apply it to our industry? Some are: http://alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+components+in+software+development http://alistair.cockburn.us/Characterizing+people+as+non-lin... From the abstract: We methodologists and process designers have been designing complex systems without characterizing the active components of our systems, known to be highly non-linear and variable (people). This paper outlines theories and projects I reviewed on the way to making this stupendously obvious but notable discovery and four characteristics of people that most affect methodology design and project outcome. I find these characteristics of people to be better predictors of project behavior and methodology success than other methodological factors.
- davidkhess 8y ago
  Very nice. Thanks for the pointer!
dragonwriter 8y ago
> Meaning, why aren't our people studying what works in other industries and figuring out how to apply it to our industry? They are and have been. For one example, much of the Lean Software Development literature leans very heavily on that. Why the things that are less systematic and empirical are more popular is a valid question, though.
- davidkhess 8y ago
  Thanks for mentioning LSD. I had not seen that yet.

mattmanser 8y ago

Isn't that what waterfall was? Replicating building a house? Gather requirements, design it, plan it, build it.

davidkhess 8y ago
Partially. But I think waterfall has (at least) two major weaknesses. The requirements are textual. They should be visual like a blueprint. A real custom home is typically visited and inspected regularly by the future home owner during construction. An improvement for waterfall would be a periodic delivery to the user of intermediate builds of the product – no matter how incomplete.
- davidkhess 8y ago
  In other words, waterfall didn't go far enough. Instead of discarding it, we should have continued to improve it.
- balfirevic 8y ago
  > A real custom home is typically visited and inspected regularly by the future home owner during construction. An improvement for waterfall would be a periodic delivery to the user of intermediate builds of the product – no matter how incomplete. May I suggest you look into this agile thing?
  - davidkhess 8y ago
    I don’t think developing a solid and complete blueprint at the beginning of the process qualifies as agile.
    - balfirevic 8y ago
      With the intention of following the blueprint all the way to the end, user wishes be damned? No, that would not qualify. But it would qualify if you actually delivered partially built product in iterations and incorporate the changes that the client requests as they inspect it, even if you preceded it with extensive blueprinting. Only in that case, it has been found that developing such detailed blueprint is very time consuming and at the same time not very useful. So we don't do it for most kinds of software projects, but not because it's against any agile principles. The original agile principles (I was just getting into software development when they were articulated) really prohibit very few things, if anything at all. But they do emphasize valuing working, useful software over following strict plan. Use planning to the exact extent that it helps you do create such software.
      - davidkhess 8y ago
        The only part of the agile approach I like is iterative delivery. First, I believe software blueprints should be put together by people with 15 to 30 years of expertise. Secondly, blueprints for a custom home are completely indispensable and are referred to regularly during construction. I believe one of the reasons why is because they are visual, not textual. I believe software requirements should be the same and then they would be easier to adjust and would retain their value. Custom homes can be adjusted in mid-build. But it is a big deal and you have to get the architect involved and potentially have your plans revetted by inspectors and the city. It's a process that has a high cost. And it should because good blueprints like good software designs are highly dependent internally. I believe every change risks degrading their quality. If you are in a project where there are large numbers of unknowns about the functionality of the project, I highly recommend shrinking the scope to what you know and actually understand. Build that, and then learn from it. Then come back around and start a new "dave's custom home waterfall" (for lack of a better name) process to implement the next set of functionality. Constantly course correcting is a recipe for never finishing and weakening quality. There should be natural impediments to course correction and scope reduction should be used until the unknowns have been reduced to a reasonable risk level.
- wink 8y ago
  I think this falls flat in terms of imagination. Look at a building shell, even if you have zero clue about houses you can see if they used rotten wood. It looks like it will become a house. The more it progresses.. well, you can easily tell "that door shouldn't be where it is" and so on. Now look at the code generated by $framework via "$tool new project $name". To a non-coder (or even just not using that language) it's not really discernible from a 90% finished product. Your house doesn't turn invisible because looked at it from the back. Also house construction follows certain "easy" patterns a 5 year old can grasp - you need to start at the bottom, you can't put the paint on before the walls are in, etc.pp - give a coder of 10 years a project in another language without documentation and you won't hear anything in the direction of "it's more 10% or 80%" unless spending days. I'm not saying people building houses have an easier job - but it's palpable.
  - davidkhess 8y ago
    To the first concern - that’s why I recommend you deliver (ideally) weekly intermediate builds of the product to the end user. Typically an underlying issue will begin to surface pretty rapidly. To the second concern, first, let’s get on the same page. When I use the home analogy it’s in regards to a custom home - not a from-plan/spec home. To your point, I believe well developed software should also have strong and obvious patterns that are reused in many if not all other projects.
  - TheCoelacanth 8y ago
    It is not remotely that simple to tell if a house is a bad one. That is why people almost always get a professional inspection before they buy one.

balfirevic 8y ago

> Meaning, why aren't our people studying what works in other industries and figuring out how to apply it to our industry? Some are: http://alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+components+in+software+development http://alistair.cockburn.us/Characterizing+people+as+non-lin... From the abstract: We methodologists and process designers have been designing complex systems without characterizing the active components of our systems, known to be highly non-linear and variable (people). This paper outlines theories and projects I reviewed on the way to making this stupendously obvious but notable discovery and four characteristics of people that most affect methodology design and project outcome. I find these characteristics of people to be better predictors of project behavior and methodology success than other methodological factors.

davidkhess 8y ago
Very nice. Thanks for the pointer!

dragonwriter 8y ago

> Meaning, why aren't our people studying what works in other industries and figuring out how to apply it to our industry? They are and have been. For one example, much of the Lean Software Development literature leans very heavily on that. Why the things that are less systematic and empirical are more popular is a valid question, though.

davidkhess 8y ago
Thanks for mentioning LSD. I had not seen that yet.