Ask HN: When Did a Small Requirement Change Cause Major System-Wide Effects?
Have you ever encountered a situation where a seemingly minor change in a requirement triggered widespread modifications across a system? What was the change, and what unexpected complexities did it introduce? How did you manage the ripple effects?
1 comments
Happens all the time. I like to call it "structural instability" [1]
I think an objective measure of software quality is that the situation you describe doesn't happen. As an experienced dev I've got a very good idea of what kind of things management don't think is small. If you have a discussion with management and decide to a cut corners relative to authentication, authorization, user onboarding, device compatibility, things core to the user experience, or managing inappropriate behavior it is very likely. that between one month and two years this will be revisited in a hurry.
(1) People are too sanguine about routine cases such as "adding a field to a form" requires: (a) creating a migration of the database schema, (b) editing a Model object on the back end, (c) editing a DAO object on the back end, (d) editing an API endpoint on the back end, (e) editing an analytics page on the back end, (f) adding a path to the API gateway, (g) editing a model object on the front end, (h) changing an JSX form on the front end, (i) adding a line of code that copies the form data to the model object, (j) changing the front end validation logic, (k) document all of the above and (l) probably fight with version control, the build system, dependencies and stuff.
Imagine another world where you make one edit to a schema and all the rest of it is code generated, 12 steps could get done to 1. (The elusive 10x productivity boost!)
This case isn't so bad because it's routine, if you are bothered by it you probably have a checklist that you can use yourself or hand to a junior dev. However, you should be consistently designing things with problems in (1) in mind, such as...
(2) Many times an application lets a user fill out N phone numbers or email addresses, say N=2. It's very likely management will decide this is not enough and mandate N=3, then N=4, ... Writing
(3) The worst case is where a (1) situation interacts with bad decisions in (2) and the design and data structures are truly bad, the bad cases are far beyond routine, but the answer is that the type (1) cases should really hurt to you, you should be always be looking at type (2) solutions to head them off, you'll be making better decisions for the type (3).
[1] https://en.wikipedia.org/wiki/Structural_stability
I think an objective measure of software quality is that the situation you describe doesn't happen. As an experienced dev I've got a very good idea of what kind of things management don't think is small. If you have a discussion with management and decide to a cut corners relative to authentication, authorization, user onboarding, device compatibility, things core to the user experience, or managing inappropriate behavior it is very likely. that between one month and two years this will be revisited in a hurry.
(1) People are too sanguine about routine cases such as "adding a field to a form" requires: (a) creating a migration of the database schema, (b) editing a Model object on the back end, (c) editing a DAO object on the back end, (d) editing an API endpoint on the back end, (e) editing an analytics page on the back end, (f) adding a path to the API gateway, (g) editing a model object on the front end, (h) changing an JSX form on the front end, (i) adding a line of code that copies the form data to the model object, (j) changing the front end validation logic, (k) document all of the above and (l) probably fight with version control, the build system, dependencies and stuff.
Imagine another world where you make one edit to a schema and all the rest of it is code generated, 12 steps could get done to 1. (The elusive 10x productivity boost!)
This case isn't so bad because it's routine, if you are bothered by it you probably have a checklist that you can use yourself or hand to a junior dev. However, you should be consistently designing things with problems in (1) in mind, such as...
(2) Many times an application lets a user fill out N phone numbers or email addresses, say N=2. It's very likely management will decide this is not enough and mandate N=3, then N=4, ... Writing
create table user (
...
phone_number varchar(20),
phone_number2 varchar(20),
phone_number3 varchar(20),
...
)
(3) The worst case is where a (1) situation interacts with bad decisions in (2) and the design and data structures are truly bad, the bad cases are far beyond routine, but the answer is that the type (1) cases should really hurt to you, you should be always be looking at type (2) solutions to head them off, you'll be making better decisions for the type (3).
[1] https://en.wikipedia.org/wiki/Structural_stability