4 ms·

>>Slow-and-steady, carefully written software isn't tolerated within many product orgs these days. The problem is that this works only for large clients and co

>>Slow-and-steady, carefully written software isn't tolerated within many product orgs these days. The problem is that this works only for large clients and conservative problem domains (such as accounting) where things change at a glacial pace. Back in the day, only such clients could afford enterprise/custom software, so using a waterfall methodology to develop that software worked well enough. Took five years to deliver the final product? No problem because the set of requirements you collected five years ago and based your software on probably still apply at the time of customer sign-off. Things have changed. Software has gotten much cheaper to develop, which means it has become way more affordable, and the types of businesses who need that kind of software are in heavy competition with each other and their problems and needs change at breakneck speed. So your best best is to have your own software development practices to match that speed.

Chris2048 6y ago
There are lots of laws and regulations around building to prevent e.g. bridges falling down. So just remove them. Now buildings have gotten much cheaper to build, which means they have become way more affordable, and the types of businesses who need that kind of building are in heavy competition with each other and their problems and needs change at breakneck speed. Failing that, keep the regulations, and apply more to software. The "needs" of business will change, and competition will move. "Slow-and-steady" needn't be glacial, and there's a lot between that and "breakneck speed". Plus there is a difference between time it takes to deliver, and frequency of requirement collection - your example implies you get requirements/sign-off exactly once before final delivery (5 years later). If we contrast "final" delivery with intermediate releases - why are the requirements not re-evaluated at each release time? You can still have slow, steady development, with lots of feedback - there just has to be an understanding that software delivered long term should not be interfered with short term concerns.

Chris2048 6y ago

There are lots of laws and regulations around building to prevent e.g. bridges falling down. So just remove them. Now buildings have gotten much cheaper to build, which means they have become way more affordable, and the types of businesses who need that kind of building are in heavy competition with each other and their problems and needs change at breakneck speed. Failing that, keep the regulations, and apply more to software. The "needs" of business will change, and competition will move. "Slow-and-steady" needn't be glacial, and there's a lot between that and "breakneck speed". Plus there is a difference between time it takes to deliver, and frequency of requirement collection - your example implies you get requirements/sign-off exactly once before final delivery (5 years later). If we contrast "final" delivery with intermediate releases - why are the requirements not re-evaluated at each release time? You can still have slow, steady development, with lots of feedback - there just has to be an understanding that software delivered long term should not be interfered with short term concerns.