4 ms·

I honestly don't care one bit how tidy someone's desk is. I've seen very good results from taking a more iterative approach as opposed to BDUF. Software is not

I honestly don't care one bit how tidy someone's desk is. I've seen very good results from taking a more iterative approach as opposed to BDUF. Software is not like building things that have been built a thousand times before. It is usually a bit more explorative, and the requirements can be hard to pin down. People aren't good at defining exactly what they want. So I find myself disagreeing with pretty much everything you say. Which is not to say that you don't need a process to manage development, or that developers will like it, whatever it is.

bitwize 2y ago
> Software is not like building things that have been built a thousand times before. It is usually a bit more explorative, and the requirements can be hard to pin down. People aren't good at defining exactly what they want. If you have a capable systems analyst, requirements are very easy to get pinned down. End users may not know what they want, but an analyst can determine what information needs the business has in order to carry out its functions by asking the right questions. Programmers are unlikely to have the big-picture vision or people skills to ask these questions; ergo, programmers make poor business analysts (but are often used as such, especially in Agile shops). What you say is typical of an immature organization where programmers are in the driver's seat, and they view themselves as artists who need to express their creativity. Information systems development is not an art but a science, and as Tim Bryce says, most programmers are not artists but house painters. See Tim's excellent challenge to these ideas and others here: https://www.linkedin.com/pulse/ten-common-myths-information-technology-tim-bryce/ https://www.linkedin.com/pulse/ten-common-myths-information-... > So I find myself disagreeing with pretty much everything you say. Which is not to say that you don't need a process to manage development, or that developers will like it, whatever it is. You may not agree with it, but that's how grown-up, effective IT organizations have been building information systems for decades now. They take a structured, factory-like approach to development, replete with an up-front design process, assembly lines, strict process control, and resource management (generally in the form of a central information-resource repository); with corporate management -- not mythical "self-organizing teams" of programmers -- in control. Most businesses do not have exotic software requirements; their information needs can be met in standard ways with standard tools and techniques. You will not see very many organizations like this in the USA. You will have to go abroad, especially to Japan. (Until recently, the Japanese did not lionize their programmers the way we do; programming was simply and strictly just another form of professional business or engineering work.) Once the West has shaken off its techbro wine (quite likely given current economic conditions), these methods will have to be rediscovered.
- MattPalmer1086 2y ago
  I have never seen great results from BDUF. It works, but you often build slightly the wrong thing or miss important requirements. I do not have much faith in business analysts. Fundamentally, its a slow and expensive way to build something that probably won't meet your actual requirements. Can it work? Sure. I bet NASA does BDUF very well. But most organisations don't have the resource and skills to pull that off.

bitwize 2y ago

> Software is not like building things that have been built a thousand times before. It is usually a bit more explorative, and the requirements can be hard to pin down. People aren't good at defining exactly what they want. If you have a capable systems analyst, requirements are very easy to get pinned down. End users may not know what they want, but an analyst can determine what information needs the business has in order to carry out its functions by asking the right questions. Programmers are unlikely to have the big-picture vision or people skills to ask these questions; ergo, programmers make poor business analysts (but are often used as such, especially in Agile shops). What you say is typical of an immature organization where programmers are in the driver's seat, and they view themselves as artists who need to express their creativity. Information systems development is not an art but a science, and as Tim Bryce says, most programmers are not artists but house painters. See Tim's excellent challenge to these ideas and others here: https://www.linkedin.com/pulse/ten-common-myths-information-technology-tim-bryce/ https://www.linkedin.com/pulse/ten-common-myths-information-... > So I find myself disagreeing with pretty much everything you say. Which is not to say that you don't need a process to manage development, or that developers will like it, whatever it is. You may not agree with it, but that's how grown-up, effective IT organizations have been building information systems for decades now. They take a structured, factory-like approach to development, replete with an up-front design process, assembly lines, strict process control, and resource management (generally in the form of a central information-resource repository); with corporate management -- not mythical "self-organizing teams" of programmers -- in control. Most businesses do not have exotic software requirements; their information needs can be met in standard ways with standard tools and techniques. You will not see very many organizations like this in the USA. You will have to go abroad, especially to Japan. (Until recently, the Japanese did not lionize their programmers the way we do; programming was simply and strictly just another form of professional business or engineering work.) Once the West has shaken off its techbro wine (quite likely given current economic conditions), these methods will have to be rediscovered.

MattPalmer1086 2y ago
I have never seen great results from BDUF. It works, but you often build slightly the wrong thing or miss important requirements. I do not have much faith in business analysts. Fundamentally, its a slow and expensive way to build something that probably won't meet your actual requirements. Can it work? Sure. I bet NASA does BDUF very well. But most organisations don't have the resource and skills to pull that off.