4 ms·

Tim Bryce’s work, such as his “Is PRIDE too rigid?” article, uses analogies with traditional engineering (like jet engine design) to argue that skipping critica

by aard 2y ago

Tim Bryce’s work, such as his “Is PRIDE too rigid?” article, uses analogies with traditional engineering (like jet engine design) to argue that skipping critical design steps can lead to costly rework later, but it stops short of offering rigorous empirical proof or extending the idea to the realm of software. "Big Design Up Front" in software is the whole reason the Agile movement came about. To put BDUF into Agile is to miss the point completely--they are fundamentally incompatible. Any company that insists on "lots of analysis and design cycles before a single line of code is written" will be left in dust by competitors if all their programmers don't quit first.

bitwize 2y ago
Tim Bryce also told the story of how he took a COBOL course in the 70s. While the programmers went straight to the keypunch and encountered numerous compiler errors, requiring recompiles, Tim pulled out his "trusty template", actually flowcharted the solution first, and then wrote the code, and it compiled and ran first time, every time. He said "That course taught me more about programmers than it did about programming." Tim's father Milt explains the industrial approach behind PRIDE here: https://m.youtube.com/watch?v=SoidPevZ7zs&t=11m20s https://m.youtube.com/watch?v=SoidPevZ7zs&t=11m20s Industrial products go through phases of specification, analysis, design, development, implementation, and review, in that order. Can you give me a reason why information systems (which, if you'd been paying attention, are much more than just software) shouldn't be the same? "Agile" sounds like skipping to implementation before the analysis or design have been completed -- going straight to the keypunch before you've documented and flowcharted exactly what you want to achieve. Of course what you're going to get is a buggy incomplete mess. But Agile says "ship the buggy incomplete mess and use your users' feedback to iterate on it!" That just annoys the users, as they just want something that works, but they have to go through many cycles of not-working software to get there. With analysts (who are emphatically NOT programmers) in the loop, employing a structured, disciplined approach to systems design and implementation, the requirements can be clarified before a single line of code is written, leading to a better result the first time, saving the organization time, money, and frustration. It's just like building a car, or a skyscraper. You need to start with a clear design so the builders know what to build. Anything else is wasting time, money, and effort. Another way of putting it is: Agile in its original form serves programmer needs while PRIDE serves management needs. Who actually runs the organization? Who has a big-picture view of what the organization's information needs are? Hint: It's not the programmers. Relevant Bryce's Laws: "Remember, it's ready, aim, fire; any other sequence is counterproductive." "A system is a product that can be engineered and manufactured like any other product."
bitwize 2y ago
Oh, and the Agile "movement" of the early 2000s was really nothing more than angry programmers looking to return to the good old days when management was so mystified by the complexity of the machine or the software it ran that programmers could do what they wanted, absent a reasonable semblance of discipline, organization, or accountability.

by aard 2y ago

bitwize 2y ago

Tim Bryce also told the story of how he took a COBOL course in the 70s. While the programmers went straight to the keypunch and encountered numerous compiler errors, requiring recompiles, Tim pulled out his "trusty template", actually flowcharted the solution first, and then wrote the code, and it compiled and ran first time, every time. He said "That course taught me more about programmers than it did about programming." Tim's father Milt explains the industrial approach behind PRIDE here: https://m.youtube.com/watch?v=SoidPevZ7zs&t=11m20s https://m.youtube.com/watch?v=SoidPevZ7zs&t=11m20s Industrial products go through phases of specification, analysis, design, development, implementation, and review, in that order. Can you give me a reason why information systems (which, if you'd been paying attention, are much more than just software) shouldn't be the same? "Agile" sounds like skipping to implementation before the analysis or design have been completed -- going straight to the keypunch before you've documented and flowcharted exactly what you want to achieve. Of course what you're going to get is a buggy incomplete mess. But Agile says "ship the buggy incomplete mess and use your users' feedback to iterate on it!" That just annoys the users, as they just want something that works, but they have to go through many cycles of not-working software to get there. With analysts (who are emphatically NOT programmers) in the loop, employing a structured, disciplined approach to systems design and implementation, the requirements can be clarified before a single line of code is written, leading to a better result the first time, saving the organization time, money, and frustration. It's just like building a car, or a skyscraper. You need to start with a clear design so the builders know what to build. Anything else is wasting time, money, and effort. Another way of putting it is: Agile in its original form serves programmer needs while PRIDE serves management needs. Who actually runs the organization? Who has a big-picture view of what the organization's information needs are? Hint: It's not the programmers. Relevant Bryce's Laws: "Remember, it's ready, aim, fire; any other sequence is counterproductive." "A system is a product that can be engineered and manufactured like any other product."

bitwize 2y ago

Oh, and the Agile "movement" of the early 2000s was really nothing more than angry programmers looking to return to the good old days when management was so mystified by the complexity of the machine or the software it ran that programmers could do what they wanted, absent a reasonable semblance of discipline, organization, or accountability.