8 ms·

> Dianne's solution creates a maintenance problem if the number of devices grows too much or if network stability is a problem, or if there is an expectation do

by mason55 13y ago

> Dianne's solution creates a maintenance problem if the number of devices grows too much or if network stability is a problem, or if there is an expectation down the line of, for instance, push sync. None of those are maintenance problems, they weren't part of the additional spec. For custom to-spec development, if the requirements change then it's expected that the code will have to change as well, incurring a change order. A maintenance problem would be something like MySQL being an unreliable DB or the code she wrote being unreadable. If someone needs to go in and fix inevitable bugs then there will be issues. If the customer wants to add features later then they'll have to pay for the changes and if the new features are different enough from the original spec then the changes might be quite expensive.

mmcconnell1618 13y ago
The ideal solution would be somewhere between a massively scalable system and a system that just barely meets expected capacity. When an engineer is designing a bridge they over-build just enough that the bridge is solid even when packed with 18 wheelers in a snow storm. Most of the time the bridge won't be anywhere near that load. A great developer builds to the expected capacity + some additional capacity based on the uncertainty of the prediction of capacity. I don't see either Jack or Dianne as perfect developers.
- prawks 13y ago
  I agree that the "bridge" should be built to the expected capacity + additional due to uncertainty, but that's a slippery slope and one that this article is trying to address. It's a judgement call on what amount of work is appropriate for what amount of capacity, as adding on more capacity due to uncertainty might delay the product or solution from launching. It may be more appropriate to properly separate concerns and build a flexible architecture that can be upgraded over time to meet needs as they come, or left as-is if those needs never manifest.

by mason55 13y ago

mmcconnell1618 13y ago

The ideal solution would be somewhere between a massively scalable system and a system that just barely meets expected capacity. When an engineer is designing a bridge they over-build just enough that the bridge is solid even when packed with 18 wheelers in a snow storm. Most of the time the bridge won't be anywhere near that load. A great developer builds to the expected capacity + some additional capacity based on the uncertainty of the prediction of capacity. I don't see either Jack or Dianne as perfect developers.

prawks 13y ago
I agree that the "bridge" should be built to the expected capacity + additional due to uncertainty, but that's a slippery slope and one that this article is trying to address. It's a judgement call on what amount of work is appropriate for what amount of capacity, as adding on more capacity due to uncertainty might delay the product or solution from launching. It may be more appropriate to properly separate concerns and build a flexible architecture that can be upgraded over time to meet needs as they come, or left as-is if those needs never manifest.