4 ms·
Well, a theory is that Agile is responsible for both. While its short devlopment cycles help deal with essential complexity (you understand better the customer'
by d--b 10y ago
Well, a theory is that Agile is responsible for both. While its short devlopment cycles help deal with essential complexity (you understand better the customer's problem because you have more interaction with them), it also implies incremental coding which often increases the accidental complexity.
As an example:
After a short development cycle, you created a database schema where each Client class has a single address, and because it was done quickly, the address fields are in the same Client table.
In a second development cycle, your customer tells you that their clients may have one or more address and one of them is the primary. The quickest path to delivery is to keep the address in the Client table as the primary address, and add a secondary address table.
While short development cycles help in not screwing up large requirements, it also impairs our ability to see the larger picture, and cause us to take decisions that we need to undo afterwards.
- arethuza 10y agoYour simple example of associating a Customer/Client to an Address is a great one - it could be that a really simply approach is required, or you may actually need the powerful features around such things that some high end ERPs support. In a previous job I spent a lot of time trying to get a shared understanding of what "customer" actually meant (this was initiated by realizing that the Customer Loss Ratios that execs wanted were really nonsense). This eventually turned out to be a non-trivial problem.
- beaconstudios 10y agothat sounds more like a symptom of forgetting to include refactoring in your agile loop, than an inherent issue with small iterations.
- d--b 10y agoYes, in this tiny example, it could be avoided by adding a simple refactor in your second iteration. In general though, the customer may ask you some iteration that he doesn't realize imply a complete rewrite of the code. Like: "now I want the same thing, but I want it available 24/7 with no downtime". Or "Now we have a great text editor, we want to add live collaboration". "You know what would be great: that we could see what changed between 2 versions of the spreadsheet".
- beaconstudios 10y agotrue, and it's hard to work around unreasonable customer requirements. In the ideal circumstance you would have that conversation and explain that having 100% uptime guaranteed is basically impossible and aiming for e.g. 6-sigma uptime requires high ongoing costs - but I'm sure we've all experienced that "I can have it both ways" attitude.