4 ms·

This post contains a lot of truth. Developers have always complained about the processes that companies employ to direct and manage software development. It c

This post contains a lot of truth. Developers have always complained about the processes that companies employ to direct and manage software development. It correctly identifies that what preceded scrum was also poor for developers (big design up front), and that if anything replaces scrum, it will also be unpleasant for developers, because all these processes do not exist to make developers happy. They exist to control and manage software development. So yeah, if you want to control how you write software, you have to be in control. But I strongly suspect that (other than for small, very high performing teams), you will inevitably create processes to manage it as you grow, and developers will then bitch about your process.

bitwize 2y ago
Indeed. To develop large information systems requires discipline and organization -- and programmers resist discipline as a mustang resists the bit. So what you have to do is break your programmers the way you break a horse -- enforce discipline upon them. They'll complain but it'll be worth it in the end. As an example, programmers often have cluttered desks citing the aphorism that "a cluttered desk is a sign of a brilliant mind" (when it's really just a sign of sloppy thinking). What you will find at highly effective software shops is that management will insist that the programmers keep a tidy desk, going so far as to bin any clutter they leave lying around -- because "neatness counts". For as much as it's maligned, "big design up front" is just common sense. The most successful methodologies for software development are derived from engineering, manufacturing, and construction -- and in those fields, having a clear idea of your requirements and a complete design or blueprint before you build, before you even prototype, is just table stakes. Anything else is stupid.
- MattPalmer1086 2y ago
  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

Indeed. To develop large information systems requires discipline and organization -- and programmers resist discipline as a mustang resists the bit. So what you have to do is break your programmers the way you break a horse -- enforce discipline upon them. They'll complain but it'll be worth it in the end. As an example, programmers often have cluttered desks citing the aphorism that "a cluttered desk is a sign of a brilliant mind" (when it's really just a sign of sloppy thinking). What you will find at highly effective software shops is that management will insist that the programmers keep a tidy desk, going so far as to bin any clutter they leave lying around -- because "neatness counts". For as much as it's maligned, "big design up front" is just common sense. The most successful methodologies for software development are derived from engineering, manufacturing, and construction -- and in those fields, having a clear idea of your requirements and a complete design or blueprint before you build, before you even prototype, is just table stakes. Anything else is stupid.

MattPalmer1086 2y ago
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.