3 ms·

I found the example given very contrived and the whole article slightly disingenuous because of it. Brooks was talking about building long-living applications

by zmmmmm 6y ago

I found the example given very contrived and the whole article slightly disingenuous because of it. Brooks was talking about building long-living applications serving complex business requirements. The article talks about a one off script with no ongoing life. It's not even really "software" at all in the terms Brooks was describing. It's like someone describing absolute limits on fuel efficiency for vehicles and then I get on a scooter and coast down a hill and jump off at the end so that it crashes into a wall and explodes, and using this example to claim they are wrong.

daotoad 6y ago
The difference between a one off script and a production-grade system with documentation, instrumentation, and monitoring is pretty big. Here's less than a minute's worth of questions I would want answered for a professional version of the log fetching example: * Is that list of a thousand servers static? * How is it updated? * What format is it in? * What do you do when the resource isn't available? * What other systems are impacted when the resource can't be contacted? * Is it acceptable to use a cached server list until it the resource can be updated? * How do you handle servers that don't respond when polled? If we retry connections, what scheme do we use? Linear or exponential back off? * After a service interruption, how do we resume data collection? Do we keep rolling forward or do we request older data? How quickly do we retrieve backed up data? Is service resumption plan different for the case when a single system is down vs when the log fetching system has an outage?
mchusma 6y ago
Agree. Nearly all the work of programming I have done is related to the task of trying to figure out the business problem in enough extreme detail to provide a solution. The main lever to improve productivity for me as a developer are open source tools, commercial APIs, and similar things. This isn't reducing the amount of programming, it's just moving it around. Magically 1,000x faster computers would maybe help me be 20% more productive.

by zmmmmm 6y ago

daotoad 6y ago

The difference between a one off script and a production-grade system with documentation, instrumentation, and monitoring is pretty big. Here's less than a minute's worth of questions I would want answered for a professional version of the log fetching example: * Is that list of a thousand servers static? * How is it updated? * What format is it in? * What do you do when the resource isn't available? * What other systems are impacted when the resource can't be contacted? * Is it acceptable to use a cached server list until it the resource can be updated? * How do you handle servers that don't respond when polled? If we retry connections, what scheme do we use? Linear or exponential back off? * After a service interruption, how do we resume data collection? Do we keep rolling forward or do we request older data? How quickly do we retrieve backed up data? Is service resumption plan different for the case when a single system is down vs when the log fetching system has an outage?

mchusma 6y ago

Agree. Nearly all the work of programming I have done is related to the task of trying to figure out the business problem in enough extreme detail to provide a solution. The main lever to improve productivity for me as a developer are open source tools, commercial APIs, and similar things. This isn't reducing the amount of programming, it's just moving it around. Magically 1,000x faster computers would maybe help me be 20% more productive.